Authentication stickiness interferes with invocations with cluster affinity

This issue was first identified in https://issues.jboss.org/browse/EJBCLIENT-216. I'm creating a separate issue here as this issue is sufficiently far removed from the original one.

When making an invocation, we use EJBClientContext.performLocatedAction(EJBLocatorlocator, LocatedAction action) to take an EJBLocator and, based on its affinity, choose a target node for the invocation from the ServiceURLs available. In order to get a connection to the chosen node, we also need to provide an AuthenticationConfiguration and an SSLContext to Remoting when obtaining the connection to the target node.

At present, the AuthenticationConfiguration and the SSLContext are stored in the EJBInvocationHandler. This was to allow authentication contexts for a JNDI context to be "sticky" (see David's comment here):
https://issues.jboss.org/browse/EJBCLIENT-216?focusedCommentId=13400915&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13400915

Unfourtunately, this allows the target node selected to change without the AuthenticationConfiguration being updated, and this in turn causes getConnection(URI uri, AuthenticationConfiguration authConfig, SSLContext sslContext) to obtain a connection to the URI specified in the stale AuthenticationConfiguration and not the target node.

The net effect is that invocations are sent to the wrong nodes:

https://issues.jboss.org/browse/EJBCLIENT-216?focusedCommentId=13400140&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13400140