We would like to revisit the `Authentication` class to make it provide better and easier to use interface to the consumers. 

#79809 enables run-as for all authentication schemes in addition to `realm` which is already supported. This adds more complexity to an `Authentication` object and how it should be used. For an example, building the role associated to an user now has to consider whether the user is the authenticated user or run-as user and the authentication scheme of the authenticated user. The existing `Authentication` class can answer all these question today. But its interface and internals are not aligned for these questions and the usage is error prone. For example, the `Authentication` object itself does not know whether the user has run-as. This information is kept by the `User` object. If the `User` object has an `authenticatedUser`, it's the run-as user. Otherwise it is not. But the information about realms for each `User` is directly kept in `Authentication`. Therefore, for full picture, the caller must check both `User` and `Authentication` realms and understands the nuance of their differenent combinations. 

- [x] Refactor CompositeRolesStore to separate roleDescriptors resolving (#80926)
- [ ] Move effective role descriptor checking from Resolver to CompositeRolesStore
- [x] https://github.com/elastic/elasticsearch/issues/81192
- [ ] Replace Authentication with AuthenticationContext in places other than CompositeRolesStore
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/Authentication.java
effectiveSubject = new Subject(user, lookedUpBy, version, Map.of());
        } else {
            authenticatingSubject = effectiveSubject = new Subject(user, authenticatedBy, version, metadata);
        }
        this.assertApiKeyMetadata();
        this.assertDomainAssignment();
    }
    /**
     * Get the {@link Subject} that performs the actual authentication. This normally means it provides a credentials.
     */
    public Subject getAuthenticatingSubject() {
        return authenticatingSubject;
    }
    /**
     * Get the {@link Subject} that the authentication effectively represents. It may not be the authenticating subject
     * because the authentication subject can run-as another subject.
     */
    public Subject getEffectiveSubject() {
        return effectiveSubject;
    }
    /**
     * Whether the authentication contains a subject run-as another subject. That is, the authentication subject
     * is different from the effective subject.
     */
    public boolean isRunAs() {
        return authenticatingSubject != effectiveSubject;
    }
    /**
     * Use {@code getEffectiveSubject().getUser()} instead.