ARTEMIS-6172 HTTP tunneling server async packets starve request replies

[brusdev]

With httpEnabled=true, Core packets are tunneled over HTTP. HttpAcceptorHandler pairs each client POST with one queued HTTP response slot; every server outbound ByteBuf must take a slot before it can be flushed.
Server-initiated / async packets (e.g. ClusterTopologyChangeMessage) also consume those slots. When they drain the queue, replies to the client’s own requests block on responses.take() until another HTTP request arrives. The client is often waiting for that reply, so the connection stalls.

After ARTEMIS-5819

• NoHttpKeepAliveRunnable→ response slots tend to accumulate and are not flushed when the broker has nothing to say.
• No idle GET → no way to create a new response slot when the queue is empty and async traffic already consumed capacity.

Proposed fix

1. Revert ARTEMIS-5819(restoreHttpKeepAliveRunnable/HttpIdleTimerand related config).
2. Fix GET handlinginHttpAcceptorHandler: on HTTP GET fromHttpIdleTimer,enqueue a new response when responses is empty(do not forward GET as a Core packet). That gives pendingResponseRunners (including replies blocked behind async packets) a slot to flush into.
3. Keep POST behavior for real traffic; empty keep-alive responses remain for the “more requests than replies” side.