upstream: net.http_proxy setting for all upstream plugins.

[pwhelan]

Summary

Add a new net.http_proxy as well as a new net.no_proxy setting that can be set both globally as well as individually for any input client or output plugin.

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• Example configuration file for the change
• Debug log output from testing the change

• Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• Run local packaging test showing all targets (including any new ones) build.
• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[leonardo-albertovich]

Please let me know if I missed something here but the thing is that there is no HTTP proxy client implementation at the moment. AFAIK it used to be implemented directly in the http client and when I created the new one I didn't include for "reasons" I can't remember.

In any case, if we are going to move it to the networking layer we'll probably need to make a few tweaks to the HTTP client to ensure that we can use it in a transient way and pass the socket around so we can establish the raw connection, use the existing HTTP client to negotiate the tunnel and then return the socket for the client code to use as if it was a freshly established connection.

[leonardo-albertovich]

As for the "old" HTTP proxy approach I think we should implement that directly in the "client" part of the HTTP client component but we should have a conversation about it to ensure that we're not mixing things around so we don't have to rework it once it's done.

[leonardo-albertovich]

This is not a complete review, I just noticed this in the log and wanted to ensure that I don't forget to bring it up.

[leonardo-albertovich]

Are these always non NULL even if empty? otherwise they might need checks.

[pwhelan]

All of those values get assigned in ``flb_utils_proxy_url_split` unless it returns -1.

[leonardo-albertovich]

Same as in flb_input_upstream_set with the additional question "why are we duplicating this code?"

[pwhelan]

I arrived late to the party so I have no idea why there is a separate file and set of APIs for input upstream versus output upstream.

I'll take a look at it and if I get anywhere open another PR to reduce the duplicate code.

[pwhelan]

Please let me know if I missed something here but the thing is that there is no HTTP proxy client implementation at the moment. AFAIK it used to be implemented directly in the http client and when I created the new one I didn't include for "reasons" I can't remember.

So the proxy implementation in the old API disappeared when the client API was re-written?

[leonardo-albertovich]

Please let me know if I missed something here but the thing is that there is no HTTP proxy client implementation at the moment. AFAIK it used to be implemented directly in the http client and when I created the new one I didn't include for "reasons" I can't remember.

So the proxy implementation in the old API disappeared when the client API was re-written?

Yes, to be specific I didn't implement it, IIRC I wanted to take the opportunity to improve the implementation rather than hacking together something sub optimal and it ended up not getting done.