Propagate max frame length to WebSocket session

[aavoronin93]

This PR ensures that maxFramePayloadLength from WebsocketClientSpec is passed to ReactorNettyWebSocketSession.

Previously, the session used the default 64KB limit regardless of client configuration, causing io.netty.handler.codec.TooLongFrameException when receiving larger frames from servers like Tomcat or Jetty.

Closes gh-36369

Before	After

I have updated the PR to include a fix for JettyWebSocketClient as well.

The issue was consistent across both clients: session-level limits were not being synchronized with the client-level configuration. For Jetty, I've implemented this by configuring the native session during initialization within the JettyWebSocketHandlerAdapter. For Reactor Netty, the maxFramePayloadLength is now correctly propagated through the session constructor.

I've also expanded the integration tests to verify the fix for both Reactor Netty and Jetty. All tests are passing.

Before	After

[aavoronin93]

Updated: While expanding the regression tests to cover all clients in WebSocketIntegrationTests, I discovered that JettyWebSocketClient suffers from the same issue.

Even when the native Jetty client (org.eclipse.jetty.websocket.client.WebSocketClient) is configured with higher limits, the JettyWebSocketSession still defaults to 64KB, leading to: CloseStatus[code=1009, reason=Text message too large: 69,624 > 65,536]

Configuration	Log	State
org.eclipse.jetty.websocket.client.WebSocketClient#setMaxFrameSize, org.eclipse.jetty.websocket.client.WebSocketClient#setMaxBinaryMessageSize, org.eclipse.jetty.websocket.client.WebSocketClient#setMaxTextMessageSize, org.eclipse.jetty.websocket.client.WebSocketClient#setMaxOutgoingFrames

[rstoyanchev]

For Reactor Netty, it looks like originally we had an maxFramePayloadLength field that was passed to ReactorNettyWebSocketSession that was then replaced in favour of the WebSocketClientSpec from Reactor Netty. However, the change 2ed281f to make the switch didn't pass the value into the session constructor, so that's a regression in 7.0.

For Jetty, however, I'm not sure yet why we need to pass the settings from the Jetty WebSocketClient to the Jetty Session, with the latter created by the former. Could you drop the Jetty changes, and submit them as a separate PR, please?

[aavoronin93]

After closer investigation, I’ve confirmed that JettyWebSocketClient correctly propagates the limits when properly configured, so I have restored JettyWebSocketClient to its original state.
The initial issues I encountered were due to local misconfiguration.