Implement simple http/grpc proxy service for testing

[pablochacin]

Exposing multiple services in the clusters used for e2e testing has become increasingly complex as the number of tests increases and new protocols are introduced.

The simplest way is to expose each service using a NodePort mapped to a port in the host running the test.

However, this easily leads to conflicts between tests that use the same port in the host, creating flakiness in the tests.

To overcome this limitation, the service proxy helper was created for using the apiserver proxy to access HTTP services without requiring additional ports.

This solution worked well for HTTP services but is not suitable for gRCP services, because the gRPC protocol does not allow adding any prefix to the URL in the requests.

One possible alternative is using an ingress, but this would require installing additional components in the test clusters and additional configuration for each service (including a TLS certificate required by the gRPC protocol)(contour's default configuration allow using gRPC with plain text connections). This additional complexity would be hard to maintain and probe to introduce more issues in the tests.

Therefore, it may be convenient to have a simple, self-contained proxy for exposing services deployed in the e2e tests. The service can be implemented by reusing the logic used by the agent for proxying HTTP and gRPC requests.

This proxy would be exposed using a single port (as happens with the ingress controllers) but will follow simple forwarding rules to the services deployed in the cluster that will require no additional configuration: it will relay in the host header received in the HTTP requests (also present in gRPC requests) to locate the service using the default Kubernetes DNS record for service.

In the future, as more protocols are added to the disruptor, this proxy can be extended to support these protocols.

[pablochacin]

An ingress controller was added to the e2e cluster setup in #160