### Description

Currently, the [`tryAuthenticateToken`](https://github.com/elastic/elasticsearch/blob/55088d154d1764a6d4fa8e9078bde9da1e9ff9a5/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/TokenService.java#L458) method calls `decodeAndValidateToken` which ends up sending two `GetRequest` for the same token ID. First in [`decodeToken`](https://github.com/elastic/elasticsearch/blob/55088d154d1764a6d4fa8e9078bde9da1e9ff9a5/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/TokenService.java#L602) and second in [`checkIfTokenIsValid`](https://github.com/elastic/elasticsearch/blob/55088d154d1764a6d4fa8e9078bde9da1e9ff9a5/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/TokenService.java#L1977). The second call is unnecessary as we already fetched the access token in the first call, it's just simply dropped. We should refactor these two methods to avoid sending second get request just to validate the access token.
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/TokenService.java
} else {
            return docId.substring(TOKEN_DOC_ID_PREFIX.length());
        }
    }
    private boolean isEnabled() {
        return enabled && Security.TOKEN_SERVICE_FEATURE.check(licenseState);
    }
    private void ensureEnabled() {
        if (Security.TOKEN_SERVICE_FEATURE.check(licenseState) == false) {
            throw LicenseUtils.newComplianceException("security tokens");
        }
        if (enabled == false) {
            throw new FeatureNotEnabledException(Feature.TOKEN_SERVICE, "security tokens are not enabled");
        }
    }
    /**
     * In version {@code #VERSION_TOKENS_INDEX_INTRODUCED} security tokens were moved into a separate index, away from the other entities in
     * the main security index, due to their ephemeral nature. They moved "seamlessly" - without manual user intervention. In this way, new
     * tokens are created in the new index, while the existing ones were left in place - to be accessed from the old index - and due to be
     * removed automatically by the {@code ExpiredTokenRemover} periodic job. Therefore, in general, when searching for a token we need to
     * consider both the new and the old indices.
     */
    private SecurityIndexManager getTokensIndexForVersion(TransportVersion version) {
        if (version.onOrAfter(VERSION_TOKENS_INDEX_INTRODUCED)) {
            return securityTokensIndex;
        } else {
            return securityMainIndex;
        }
    }
    /**