Handle error cases for embedded apps using token exchange strategy

[rezaansyed]

WHY are these changes introduced?

Fixes https://github.com/Shopify/develop-app-access/issues/135 & https://github.com/Shopify/develop-app-access/issues/136

WHAT is this pull request doing?

• Handles invalid session token errors on request
  • Document request: redirect to bounce page
  • XHR: 401 with App Bridge retry request header
• Handles invalid subject token error on token exchange
  • Document request: redirect to bounce page
  • XHR: 401 with App Bridge retry request header
• Handles invalid access token on API request
  • Document request: Delete the access token and redirect to bounce page (which eventually triggers token exchange)
  • XHR: Delete access token and return 401 without App Bridge retry header (since part of the request may already have been processed).

Type of change

• Patch: Bug (non-breaking change which fixes an issue)
• Minor: New feature (non-breaking change which adds functionality)
• Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have used yarn changeset to create a draft changelog entry (do NOT update the CHANGELOG.md files manually)
• I have added/updated tests for this change
• I have documented new APIs/updated the documentation for modified APIs (for public APIs)

[paulomarg]

Should this be throwing?

[paulomarg]

I like the solution of having the strategy determine how we handle errors, but I'm a little on the fence about passing in the entire auth strategy as a parameter for creating the context, it feels like we're mixing concerns a little bit.

What if, instead of passing the strategy in to handleClientErrorFactory, we have the strategy export its own flavour of handleClientErrorFactory, something like

  public async handleClientError({
    request,
    session,
  }: StrategyHandleClientErrorOptions): Promise<HandleAdminClientError> {
    const {config, api, logger} = this;
    return handleClientErrorFactory({
      onError: // Do token exchange things
    });
  }

That way, each strategy can determine how it handles the errors and they all subscribe to a common interface without the strategy having to be shared around.

IIRC handleClientErrorFactory is pretty much tied to the strategy already anyway, so it shouldn't really affect anything else. Perhaps it makes more sense for the strategy to just export a callback for its own error handling.

Does that sound sensible?