fix: add getAuthToken method to AuthenticationPlugin interface

[nateab]

Description

Websocket pull queries that were forwarded to a different node were not correctly extracting their required credentials from the original pull query request. This PR fixes this by adding a getAuthToken method to the AuthenticationPlugin interface, with the default being the original behaviour of checking only for an Authorization header, and plugins being able to add any custom authentication they need for multi-node websocket pull queries.

Testing done

Integration test added

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[AlanConfluent]

Just to understand a bit better, do we have a case where the WS was used with an authentication plugin where the header wasn't what was used for authentication? Does this have anything special to do with the WebSocket vs any other interface? Just to be clear, when the requests are forwarded, they are done using the /query endpoint regardless of which they came in on.

[AlanConfluent]

Maybe add an additional comment here about how this is different from handleAuth. This is a little funny because we expose the auth token (as opposed to just treating it as entirely internal to the plugin, as handleAuth does) in addition to exposing handleAuth, since we need it for the purpose of forwarding on requests inter-node as using it as a backup header for connect. Since we need it for those two purposes, I don't think we can easily hide it in a plugin method like prepareRequest().

Also, I assume that since this is default, it shouldn't break any existing plugins.

[nateab]

Added a javadoc explaining why we need to expose this method. And yes the default just defaults back to the old logic so that nothing existing should break.

[nateab]

@AlanConfluent the internal jira that I slacked you has more context about how we identified the problem, but essentially it is because the WS requests do not use Authorization headers for authorization, they use either query params or cookies. So when the request was forwarded, it would only check the header which would be null since we didn't use it in the original WS request.