How to handle missing extensions?

The process of negotiating handshakes is clearly defined in section 3.1.3
> In the opening handshake, the client supplies a list of extensions that it would like to use. The default server configuration selects from those extensions the ones it supports, and places them in the same order as requested by the client.

What isn't discussed is what happens if `ClientEndpointConfig#getExtensions()` returns one or more extensions that the client side code does not recognise. An equivalent question applies to `ServerEndpointConfig#getExtensions()`.

The TCK currently assumes that if the `ClientEndpointConfig` or `ServerEndpointConfig` declares an extension, it will be supported. The TCK then defines 3 random extensions and assumes both the client and the server will ignore the fact they don't recognise the extensions (since they can't possibly support them).
Assuming that an unknown extension will be ignored could be problematic. If a genuine extension is declared by both the client and server and those endpoints are deployed in an environment where only one side recognises the extension it is likely that attempts to use the endpoints will fail as one endpoint tries to use an extension the other has declared support for but doesn't actually understand.

I'm currently thinking through what a fix for this might look like. I suspect it will have to wait for Jakarta EE 10 but maybe not.

Start by reading section 3.1.3 and the behavior of ClientEndpointConfig#getExtensions() and ServerEndpointConfig#getExtensions(). Review the TCK assumptions about its three random extensions and determine what behavior the specification and TCK should require for unrecognized extensions. Done requires an agreed resolution, rather than the current open design discussion.

Written by the indexing model from the issue text.