feat(clustering) support http forward proxy

[fffonion]

Summary

Allow Dp -> Cp connection to go through a HTTP proxy tunnel. Only HTTP proxy is supported for now.

Things to do after feature frezze before code freeze:

• Make our patch of lua-resty-websocket.client a patch instead of vendoring
• Add support of talk to an HTTP tunnel in https

Full changelog

• Add forwrd proxy support for clustering data plane

Issue reference

FTI-2996

[fffonion]

For reviewers:

• patch of websocket.client is done in a seperate commit
• tests is coming
• will move the vendored websocket.client to a patch once CI pass and review is good

[flrgh]

We now have our own fork of lua-resty-websocket for any of our extra features that haven't made it upstream yet.

I think we should try to get this change into the fork and then ship it with OSS (currently it's only packaged in EE, but it is trivial to add to OSS). It is currently installed by kong-build-tools in-place of resty.websocket, so any changes/additions just need to be backwards-compatible, but this hasn't proved to be too much of a challenge yet. Feel free to @/ping me for help and/or code review if needed.

If it's not feasible to do make this change before code freeze, would you be willing to do so in a follow-up PR? I'd like us to not have to maintain multiple versions of this library.

[fffonion]

@flrgh exactly, vendoring this is not a good idea. RIght now i'm vendoring it so I can test it in a single PR (and
it's easier to tell what did we change).
We already have patch for lua-resty-websocket, so adding another one won't bring more burden. So yes I will make this a proper patch and remove the vendoring
after feature freeze.

[flrgh]

We already have patch for lua-resty-websocket, so adding another one won't bring more burden.

To explain why I'm pushing for Kong/lua-resty-websocket over openresty-patches approach:

Any build that bundles Kong/lua-resty-websocket (currently just EE) overwrites the entire resty/websocket tree after OpenResty patches are applied. The reason this doesn't cause any breakage in EE today is because Kong/lua-resty-websocket was forked from OpenResty/lua-resty-websocket:master, so it already contains the unreleased client mtls commit(s).

What this means is that any new features/patches added to openresty-patches in kong-build-tools that don't already exist upstream must be ported to be Kong/lua-resty-websocket, or there will be breakage in EE. So it puts us in the place of needing to maintain separate patches in two different repositories against codebases that are already diverging over time.

---

An aside: the reason for overwriting resty.websocket rather than using our own namespace (i.e. kong.resty.websocket) is historical. I don't believe there's anything today stopping us from namespacing it and shipping it via luarocks rather than the clunky KBT install process, if we so choose. There just hasn't really been any friction with the current process until now.

[hbagdi]

Please make sure to add a kong.conf.default entry as part of this PR.

[chronolaw]

Should we add proxy_server and cluster_use_proxy in spec/fixtures/custom_nginx.template?

[fffonion]

@chronolaw proxy_server and cluster_use_proxy are kong.conf entries and won't affect the nginx template
(for now).

[dndx]

Approved with minor style recommendation, and can be merged after they have been addressed and tests are green.

We need to remove the copied code from lua-resty-webaocket still, but it is decided to do that in a separate PR.