Fix processing of the SASL server success message for shared-connection authentication

ELY-1380 ensures that the SASL getNegotiatedProperty() method throws an IllegalStateException if it's called before negotiation is complete. With the changes for ELY-1380, the WildFly master testsuite hangs in org.wildfly.test.manual.elytron.seccontext.SecurityContextPropagationSLSFTestCase#testClientOauthbearerInsufficientRolesFails. Note that the hang only affects WF Core 4 / WF 12 since the changes for ELY-1380 aren't part of the Elytron 1.1.x branch. The hang is due to a couple of issues:

1. After receiving a correct initial response from the client, OAuth2SaslServer#evaluateMessage returns an array with zero length. This array is supposed to get processed by OAuth2SaslClient#evaluateChallenge in order for the client to set its negotiation state to COMPLETE_STATE. However, this is what's currently happening instead:

• In RemoteReadListener#handleEvent, when processing the APP_AUTH_SUCCESS message from the server, the final challenge is getting interpreted as null instead of as NO_BYTES.
• In ConnectionPeerIdentityContext#doAuthenticate, when processing the success message, OAuth2SaslClient#evaluateChallenge won't get called since the challenge is interpreted as null. Thus, the client won't change its state to COMPLETE_STATE, resulting in an IllegalStateException being thrown if getNegotiatedProperty() is called.

2. In ConnectionPeerIdentityContext#doAuthenticate, getNegotiatedProperty() is called after the SASL client has been disposed. Since OAuth2SaslClient#dispose sets the negotiation state to FAILED_STATE, calling getNegotiatedProperty() after will result in an IllegalStateException being thrown.

The following PR fixes the hang by:

• ensuring that SaslClient.evaluateChallenge() gets called when processing the success message from the server if SaslClient.isComplete() returns false
• ensuring that getNegotiatedProperty() is called before dispose() is called on the SASL client in ConnectionPeerIdentityContext#doAuthenticate

https://github.com/jboss-remoting/jboss-remoting/pull/157

Note that the above changes for shared-connection authentication are similar to what is currently done for initial connection establishment.