Support full-duplex http1.1

[jackkleeman]

Go http servers do support fully bidirectional http1.1 (ie you can start streaming back a response body while the request body is still streaming) as long as EnableFullDuplex is called. Some services downstream of the interceptor (eg, restate services) may rely on this functionality, so by enabling this in our http server we enable those kinds of services. We will not fail if the option can't be enabled, but we will log. However it works with the current stdlb and there is no reason to expect that to change!

Checklist

• [x] Commits are signed with Developer Certificate of Origin (DCO)
• [x] Changelog has been updated and is aligned with our changelog requirements
• [x] Any necessary documentation is added, such as:
  • README.md
  • The docs/ directory
  • The docs repo

[snyk-io[bot]]

:white_check_mark: Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
:white_check_mark:	Open Source Security	0	0	0	0	0 issues

:computer: Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[jackkleeman]

We could test that the enable flag doesn't return an error, for a default server? Beyond that we'd be testing the behavior of the go stdlib, which probably isn't worth it

[linkvt]

Yeah I agree that testing go internals and testing that we call it don't make much sense - I think it was cleaner without the tests 😀 . I was thinking about some kind of e2e test but thats probably a bit harder to do and maybe not required/worth it.

I'm also just reviewing because I'm interested so my judgement isn't worth much as it's up to the reviewers to decide.

[jackkleeman]

i think its good to test that responsewriter correctly passes through the command, and we already have tests for hijacker for the same thing. the one on servecontext i dont mind so much