Fix oidc authToken not getting passed through to websocket connection open for Events Api

[NWylynko]

Description of changes

While attempting to use the new Event Api with Appsync, I wanted to authenticate using clerk.com, using there jwt templates feature I created an aws template and then came back to aws and setup the OpenID Connect authorization mode. But despite getting the token generated and passed through to the events.connect() method as the authToken, it would always fail to connect with error: "Required Headers are missing". Doing some digging in the code found that the options.authToken was effectively being ignored, and then on top of that it was still just trying to use the Amplify auth token. So I have updated the code to use the supplied jwt token.

Issue #, if available

Description of how you validated changes

I updated the raw js files in my project i am working on and was able to get the client to authorise with the websocket and receive messages, I can also see in the network tab of the dev tools that the jwt generated by Clerk is being passed through the headers of the connection.

Checklist

• PR description included
• yarn test passes
• Unit Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

Checklist for repo maintainers

• Verify E2E tests for existing workflows are working as expected or add E2E tests for newly added workflows
• New source file paths included in this PR have been added to CODEOWNERS, if appropriate

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[iartemiev]

This change breaks the expected behavior for OIDC auth for both Events and GraphQL subscriptions. By default, this auth mode is meant to work with the OIDC configuration provided through Amplify Backend and sign in/sign out handled via Amplify Auth. When configured this way, we automatically extract the OIDC access token from the currently signed in user in the awsAuthTokenHeader function and pass it through to the subscription auth token. This functionality must remain intact.

That being said, I agree that we should allow a fallback to a manually-managed authToken passed in through the client's public API. I think we can do that by conditionally calling either the existing customAuthHeader or awsAuthTokenHeader depending on whether an explicit authToken was specified at the client call site.