agent/http: refactor proxy for simpler error handling

[roobre]

Description

This PR introduces a small refactor in the HTTP proxy, so it is easier to read the logic behind delays, faults, and proxies.

Fixes #252

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make test) and all tests pass.
• I have run relevant e2e test locally (make e2e-xxx for agent, disruptors, kubernetes or cluster related changes)
• Any dependent changes have been merged and published in downstream modules
  

[pablochacin]

Hi @roobre Overall, the changes make sense and improve the code, except for the usage of a channel for waiting. I suggest an alternative approach that I think is simpler to reason about.

[pablochacin]

I find confusing this wait channel. I think it obscures the purpose of the proxy which should in my opinion only do one thing.

I suggest that instead of passing this argument, you use a wrapper function that waits before (or after) the given delay and then calls a function passed as an argument, given that both proxy and fault has the same signature.

[roobre]

The main purpose of the wait channel is to allow to start waiting after the request has been made. This way, the latency to the upstream service is "included" in the fault latency. I wasn't able to figure out a way of doing this with a wrapper, as this wait necessarily needs to happen after performing the request, but before writing the response.

Do you have an idea for how to get rid of the channel but maintain this feature?

Otherwise, we can just drop the feature and always sleep before initiating the request upstream.

[pablochacin]

I don't have any off the top of my head, but at the very least, I would pass the delay and make the wait inside the functions instead of passing a channel. That makes the purpose of the argument clear. I don't see any advantage on using a channel.

[pablochacin]

Same comment here. I find this wait argument confusing and cannot see how it improves or simplifies the code or the error handling.

[pablochacin]

LGTM. Made a couple of comments about the naming of some functions because I find them odd.

[roobre]

Rebased and squashed, feel free to merge if you don't have further concerns @pablochacin.