Fix broken client tls negotiation

[lorban]

When the Jetty client needs to negotiate TLS with the server, it fails to do so and cannot open a connection.
The only indication is the following debug log:

2024-07-03 10:40:19.579:DEBUG:oeji.FillInterest:HttpClient@59d016c9-24: onFail FillInterest@40dda3e8{null}
java.nio.ReadOnlyBufferException
	at java.base/java.nio.HeapByteBufferR.put(HeapByteBufferR.java:246)
	at org.eclipse.jetty.util.BufferUtil.put(BufferUtil.java:460)
	at org.eclipse.jetty.util.BufferUtil.append(BufferUtil.java:549)
	at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.fill(SslConnection.java:830)
	at org.eclipse.jetty.io.NegotiatingClientConnection.fill(NegotiatingClientConnection.java:102)
	at org.eclipse.jetty.io.NegotiatingClientConnection.onFillable(NegotiatingClientConnection.java:84)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
	at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:574)
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:390)
	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:150)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
	at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produce(AdaptiveExecutionStrategy.java:195)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209)

This happens because we mistakenly pass a read-only empty byte buffer to a fill() method that tries to append to it, so it fails with an exception instead of returning that zero byte was copied.

Fixes #11965

[sbordet]

I think it's going to be difficult to know when to use one constant vs the newly introduced one.

Can we make the old constant non-read only?

[sbordet]

See comment.