poc: tcp proxy

[nadiamoe]

Description

This PR introduces, as a PoC, a TCP proxy.

The TCP proxy allows building disruptors that work on top of TCP connections, and thought to be a base for building protocol-specific disruptors for those protocols that do not have a server implementation in go, like databases and message queues.

The TCP proxy allows this by defining the following interface:

	// HandleUpward forwards data from the client to the server. Proxy will call each method exactly once for the
	// single connection a Handler instance handles. Implementations should consume from client and write to server
	// until an error occurs.
	// When either HandleUpward or HandleDownward return an error, connections to both server and clients are closed.
	// If ErrTerminate is returned, the connection is still closed but no error message is logged.
	HandleUpward(client io.Reader, server io.Writer) error
	// HandleDownward provides is the equivalent of HandleUpward for data sent from the server to the client.
	HandleDownward(server io.Reader, client io.Writer) error

Protocol-specific disruptors can be built by implementing Handlers that decode the data sent in the buffers, to the extent the disruptor needs.

The ConnMeta struct contains information about the connection, such as the downstream and upstream address.

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
  

[nadiamoe]

promlinter'seems to be panicking with a somewhat cryptic message:

level=warning msg="[runner] Can't run linter goanalysis_metalinter: goanalysis_metalinter: promlinter: package \"tcp\" (isInitialPkg: true, needAnalyzeSource: true): runtime error: index out of range [0] with length 0"

At first sight this looks like a bug in promlinter, but I'm not sure what is triggering it.

[pablochacin]

Building TCP-level disruptors, such as connection dropping and delays

I think we should not promote this proxy for such TCP disruptions because a byte stream seems not to be a good abstraction for modeling network issues. Packages (package lost, package delays) are commonly used for modeling such disruptions.

Besides, there are tools such as tc that can inject these faults and are widely used by the chaos engineering teams.

[nadiamoe]

That makes sense. Stream-level, raw TCP disruptions are not the way infrastructure and network-adjacent folks are used to think. Leveraging tc is definitely the way to go for network-level disruptions.

Let's keep iterating on this with the framework for protocols in mind. If, in the far future, we find use cases that tc does not cover, we can think about whether they fit here or not.