Reset the stream when a response is completed before its corresponding response

[jrhee17]

Motivation:

The motivation for this PR is better stated in #6104.

Modifications:

• Modified so that when a request is aborted with a ResponseCompleteException, the stream is reset with CANCEL for http2 or the connection is closed for http1.

Result:

• Connections do not hold references on automatically aborted requests, resulting in less memory pressure.

[github-actions]

🔍 Build Scan® (commit: 7a52a46)

Job name	Status	Build Scan®
build-ubicloud-standard-16-jdk-8	✅	https://ge.armeria.dev/s/hvs3b555uft6o
build-ubicloud-standard-16-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/fgdqqiag5elco
build-ubicloud-standard-16-jdk-17-min-java-17-coverage	✅	https://ge.armeria.dev/s/gj5oztbdnyica
build-ubicloud-standard-16-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/vkijnd5mayf4m
build-ubicloud-standard-16-jdk-17-leak	✅	https://ge.armeria.dev/s/chjzbrwgpjqny
build-ubicloud-standard-16-jdk-11	✅	https://ge.armeria.dev/s/dmknnxu5wlvak
build-macos-latest-jdk-21	❌ (failure)	https://ge.armeria.dev/s/sv3m7evugk56y

[ikhoon]

It makes sense regarding the modifications made on the client side.

Server-side question) It could be unsafe to indefinitely wait for the client to send EOS in the half-closed (local) state.
Would it be reasonable to send RST_STREAM on the server side after requestAutoAbortDelay if the request remains open?

[ikhoon]

nit: cause instanceof ResponseCompleteException should be cheaper and is more likely to be called.

Suggested change

	if (Exceptions.isStreamCancelling(cause) || cause instanceof ResponseCompleteException) {
	if (cause instanceof ResponseCompleteException || Exceptions.isStreamCancelling(cause)) {

[ikhoon]

Would it be reasonable to send RST_STREAM on the server side after requestAutoAbortDelay if the request remains open?

/cc @minwoox Maybe he has some thoughts on that.

[minwoox]

Would it be reasonable to send RST_STREAM on the server side after requestAutoAbortDelay if the request remains open?

That makes sense. 👍

[jrhee17]

Server-side question) It could be unsafe to indefinitely wait for the client to send EOS in the half-closed (local) state.
Would it be reasonable to send RST_STREAM on the server side after requestAutoAbortDelay if the request remains open?

If you have an idea to handle this, feel free to do so. I don't think this issue is trivial, and I think some more time is needed to analyze/fix this issue.

[ikhoon]

Server-side question) It could be unsafe to indefinitely wait for the client to send EOS in the half-closed (local) state.
Would it be reasonable to send RST_STREAM on the server side after requestAutoAbortDelay if the request remains open?

If you have an idea to handle this, feel free to do so. I don't think this issue is trivial, and I think some more time is needed to analyze/fix this issue.

I didn't take a look at the problem in detail. It seems you have analyzed the issue more than I have, so I would like to ask you to handle it.

[minwoox]

Let's handle the server-side issue separately. Thanks!