Envoy extensions for reverse connections

[basundhara-c]

Commit Message: This commit collates the envoy extensions for reverse connections, described in this github issue. A detailed description of the changes is provided in examples/reverse_connection/README.md. This PR is strictly tied with #37368.
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Signed-off-by: Basundhara Chakrabarty basundhara.c@nutanix.com
Co-authored-by: Arun Vasudevan arun.vasudevan@nutanix.com
Co-authored-by: Tejas Sangol tejas.sangol@nutanix.com
Co-authored-by: Aditya Jaltade aditya.jaltade@nutanix.com

[repokitteh-read-only]

Hi @basundhara-c, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #37367 was opened by basundhara-c.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy[\w/]*/(v1alpha\d?|v1|v2alpha\d?|v2))|(api/envoy/type/(matcher/)?\w+.proto).
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @abeyad
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #37367 was opened by basundhara-c.

see: more, trace.

[wbpcode]

Hi, thanks for contribution to Envoy. But any new extension should be sponsored by one of maintainer to ensure the extension meet our requirements (style, etc.)

Did you find any one to help with this new extension?

[alyssawilk]

It's great to have this for the use case but I suspect it makes sense to review one at a time. Also per extension guidelines unless there's a maintainer sponsor this should go in contrib/
/wait

[basundhara-c]

@alyssawilk thanks for taking a look! I'll be separating this PR into one per extension shortly. Would you consider sponsoring this feature since you've given us several suggestions on the design and might be familiar with the flow?
Additionally, for adding the code to contrib/, since extensions added to contrib/ are not compiled in a main image build, we may not be able to instantiate objects for classes defined in contrib/ in envoy core, am I right? We are concerned about these three cases where we are including files defined in extensions in envoy core:

1. Creating a ReverseConnectionListenerImpl here with the reverse conn parameters
2. Here where the Connection Handler creates an ActiveReverseConnectionListener which triggers the reverse conn creation.
3. Where the Cluster Manager determines whether to use a request needs to be sent over a reverse connection and calls the Reverse connection custom conn pool

In cases 1 &2 , we can get away by creating classes for ReverseConnectionListenerImpl and ActiveReverseConnectionListener in envoy core and in case 3, we could have the custom conn pool implementation under Http::Http2 in envoy core, but this would mean more changes to envoy core. What do you think?

[alyssawilk]

Regarding sponsorship I'm sorry but I'm not able to help there. Adding new code to Envoy adds a bunch of scut work to the maintainers. There are many more extensions to the envoy code base than the (functionally understaffed) maintainer team can afford to maintain, so generally if folks want things in the main build they either have to have enough clear value add that one of the maintainers will sign on for the work, or the folks proposing it eventually sponsor maintainers to move it from contrib to main, at which point they implicitly help with the load. Contrib allows folks to use the contrib builds for pre-built Envoys with their code, as if there's a bunch of use and uptake, eventually one of the maintainers may pick it up

[basundhara-c]

@wbpcode I haven't found a sponsor yet and am actively looking for one!
@alyssawilk I understand, and thank you for considering!
I am evaluating whether we can move the extensions to contrib/, particularly, on finding a way/alternative to instantiating classes defined in contrib/ within envoy core. We are doing it in the three cases mentioned in the previous comment:

1. Creating a ReverseConnectionListenerImpl here with the reverse conn parameters
2. Here where the Connection Handler creates an ActiveReverseConnectionListener which triggers the reverse conn creation.
3. Where the Cluster Manager determines whether to use a request needs to be sent over a reverse connection and calls the Reverse connection custom conn pool

We can maybe avoid this but it might cause some more changes in envoy core. Any suggestions would be welcome!

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[basundhara-c]

@alyssawilk @wbpcode this has been split into several contrib/ extensions as described in the PR containing core changes:
#37368

PRs with contrib/ extensions:
"envoy.filters.http.reverse_conn" HTTP filter: #37822
"envoy.bootstrap.reverse_connection" bootstrap extension: #37819
"envoy.filters.listener.reverse_connection" listener filter: #37821
"envoy.reverse_connection.reverse_connection_listener_config" listener that initiates reverse connections: #37820