Handle response correctly when request already cancelled

[nicktindall]

Related to #109866

Since #110118 the test fails under the same circumstances, but in a different way.

Now, when processResponse executes after the cancellation has completed (localRefs.hasReferences() == false) - but before the channel is closed (RestActionListener.ensureOpen() passes), the call to mustIncRef() fails because the reference counts have already reached zero. This change uses tryIncRef() instead, double-checking on a failure that hasReferences() == false (although I'm not sure whether that bit is necessary)

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)

[nicktindall]

This feels like it could hide the test being broken (i.e. if we always cancel before the call to processResponse it'll happily pass without testing anything).

Another approach would be to put a synchronization point after the call to sendResponse, which we wait on before cancelling the request. That way we could be sure we'd begun sending the response before the cancellation? but perhaps handling cancellation prior to the response being sent is part of the test?

[nicktindall]

I guess we could just call tryIncRef, and if it fails to increment the counter, it should also not decrement it later (by virtue of channel.sendResponse not sending the chunked response)?

[ywangd]

I think the current change is fine. We also do something similar at prepareRequest a few lines above.

elasticsearch/modules/transport-netty4/src/internalClusterTest/java/org/elasticsearch/http/netty4/Netty4ChunkedContinuationsIT.java

Line 637 in ef52f8c

if (localRefs != null && localRefs.tryIncRef()) {

perhaps handling cancellation prior to the response being sent is part of the test?

I think so. The random sleep in the test method is intended to have cancellation happen in different places, including in prepareRequest where no response is ever generated.

it should also not decrement it later (by virtue of channel.sendResponse not sending the chunked response)?

I think this might not be the case. It seems that response is released if channel.sendResponse fails to send.

elasticsearch/server/src/main/java/org/elasticsearch/http/DefaultRestChannel.java

Lines 191 to 192 in ef52f8c

	if (success == false) {
	Releasables.close(toClose);

[ywangd]

LGTM