token invalidation outside of a single lib core ims context is not handled

[moritzraho]

Describe the bug
If I have a context configuration that holds an access_token and/or refresh_token and that it gets invalidate outside of this context, then on the next getToken, as long as the token is not expired it will be returned although it's invalid.

This applies for both action and cli config

Reproduce

const { Ims, getToken, invalidateToken, context } = require('.')

const config = {
    client_id: "<jwt-clientid>",
    client_secret: "XXX",
    techacct: "<guid>@techacct.adobe.com",
    meta_scopes: [
      "ent_dataservices_sdk"
    ],
    ims_org_id: "<org-guid>@AdobeOrg",
    private_key: "XXX"
}

await context.set('my-ctx', config)
const token = await getToken('my-ctx')

// await invalidateToken('my-ctx') => would delete the token in the config

// but if the token is invalidate elsewhere the token would still be in the config
// example
const ims = new Ims('prod')
await ims.invalidateToken(token, config.clientId, config.clientSecret)

const token2 = await getToken('my-ctx') // would return the same cached token which is invalid
// furthermore now a call to invalidateToken will throw an error as the token is not valid

Possible solution
in every getTokenIfValid call in token-helper.js validate the token against IMS, however this will trigger many more requests and reduces the advantage of caching the token

[shazron]

I'm thinking invalidateToken should just clear out the cached token.

[moritzraho]

yeah it does so already, it's regarding invalidation of the token done outside of the context or outside of aio-lib-core-ims