TCK: unknown extensions behavior

[joakime]

Challenged tests
com.sun.ts.tests.websocket.signaturetest.WebSocketSigTestIT.signatureTest()

TCK Version
HEAD (likely equivalent to 2.2)

Description
The TCK tests that custom extensions can be negotiated, however if an unknown extension is tried to be negotiated in Eclipse Jetty we do not allow it to be sent from the client as no implementation exists (extensions implementations are an Eclipse Jetty websocket-core mechanism which can be added through the service loader). The only extension Eclipse Jetty supports is permessage-deflate so any other extensions cannot be requested by the client unless the WebSocketClient knows an implementation for this extension name.

Additional context
Either the behavior of not sending an extension that doesn't exist is the behavior we want, or that the TCK clearly state that there are extensions that the implementation of Jakarta WebSocket (eg: Eclipse Jetty TCK code) must implement for the TCK to pass.

[joakime]

CC @lachlan-roberts

[markt-asf]

This ties in with #340. In terms of how we manage to get this working with the TCK, would it be reasonable for the TCK to require one (or possibly more) NO-OP extensions to be implemented on the client and/or server that could then be used to test the extension behaviour?

[lachlan-roberts]

I think its reasonable to require implementation of a set of custom extensions if it is documented somewhere.

The workaround that worked for us was to implement NO-OP implementations for all the custom extensions that were used in the TCK.

Which were ext1, ext2, firstExtName, secondExtName and thirdExtName.