Issue #7078 - share inflater/deflater pools for websocket in jetty 9.4

[lachlan-roberts]

Closes #7078

These changes bring the sharing of the CompressionPools closer to what is done by WebSocketServerComponents in Jetty 10.

• Share the InflaterPool and DeflaterPool as beans on the Server.
• Make the default pool size based off the max number of threads from the ThreadPool.
• Allow pools to be set per context with the ServletContext attributes jetty.websocket.inflater and jetty.websocket.deflater.

[joakime]

Make the default pool size based off the max number of threads from the ThreadPool.

Would a user using jakarta.websocket API with streaming message delivery complicate this? (as those cause new threads)

[lachlan-roberts]

Would a user using jakarta.websocket API with streaming message delivery complicate this? (as those cause new threads)

@joakime I don't think this is an issue because there will still not be any more than maxThreads going through the permessage-deflate extension at any one time.

The DispatchedMessageSink also uses the ThreadPool so there should still be no thread acquiring two delfaters/inflaters simultaneously. And if this were to happen and the pool was to exceed capacity, it would create non-pooled entries which are discarded on release and it calls the deflater.end() method.

[lachlan-roberts]

@gregw @joakime can I get a review on this.