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
assert false == isServiceAccount();
        final Authentication newTokenAuthentication = new Authentication(
            getUser(),
            getAuthenticatedBy(),
            getLookedUpBy(),
            getVersion(),
            AuthenticationType.TOKEN,
            getMetadata()
        );
        assert Objects.equals(getDomain(), newTokenAuthentication.getDomain());
        return newTokenAuthentication;
    }
    /**
      * The final list of roles a user has should include all roles granted to the anonymous user when
      *  1. Anonymous access is enable
      *  2. The user itself is not the anonymous user
      *  3. The authentication is not an API key or service account
      *
      *  Depending on whether the above criteria is satisfied, the method may either return a new
      *  authentication object incorporating anonymous roles or the same authentication object (if anonymous
      *  roles are not applicable)
      *
      *  NOTE this method is an artifact of how anonymous roles are resolved today on each node as opposed to
      *  just on the coordinating node. Whether this behaviour should be changed is an ongoing discussion.
      *  Therefore, using this method in more places other than its current usage requires careful consideration.
      */
    public Authentication maybeAddAnonymousRoles(@Nullable AnonymousUser anonymousUser) {
        final boolean shouldAddAnonymousRoleNames = anonymousUser != null
            && anonymousUser.enabled()
            && false == anonymousUser.equals(getUser())