…yproxy#1757)

Signed-off-by: Matt Klein <mklein@lyft.com>

Description:

A few considerations:
- It's critical to set the right environment variables for coverage builds to work (this is how Bazel controls how coverage is run), in particular we need to set CC, CXX, GCOV and BAZEL_LLVM_COV to point to the right tools and they need to exist in the docker container that's running the builds.
- BAZEL_USE_LLVM_NATIVE_COVERAGE is required for bazel to run LLVM coverage
- These environment variables affect the rbe_autoconfig toolchain generation (i.e. the generated packages will point to different places depending of those env variables), so we need a new toolchain just for coverage.

Some shortcomings / gotchas:
- Coverage builds depend on config=coverage from upstream Envoy, as such, the coverage actions run locally (probably because remote coverage builds are buggy), because of this we need test_strategy=standalone to run the tests locally and produce the right coverage artifacts.
- After my experimentation, coverage builds seem to be incompatible with remote_download_outputs=toplevel (or minimal) so we need to set it to remote_download_outputs=all. Otherwise, some coverage artifacts aren't present locally for the coverage report generation. This is a bug in Bazel and I'll file a bug upstream for that.
- Similar experimentation shows that remote caching is also incompatible with remote coverage. For some reason, caching makes prevents some of the coverage artifacts to be present locally and the report generation consistently fails. This is another bug from Bazel (I'll file another issue for this).

Last, I've added a remote-ci-debug config to print various different streams of data from different Bazel stages

Risk Level: Low
Testing: See coverage workflow
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: Luis Fernando Pino Duque <luis@engflow.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description:

A few considerations:
- It's critical to set the right environment variables for coverage builds to work (this is how Bazel controls how coverage is run), in particular we need to set CC, CXX, GCOV and BAZEL_LLVM_COV to point to the right tools and they need to exist in the docker container that's running the builds.
- BAZEL_USE_LLVM_NATIVE_COVERAGE is required for bazel to run LLVM coverage
- These environment variables affect the rbe_autoconfig toolchain generation (i.e. the generated packages will point to different places depending of those env variables), so we need a new toolchain just for coverage.

Some shortcomings / gotchas:
- Coverage builds depend on config=coverage from upstream Envoy, as such, the coverage actions run locally (probably because remote coverage builds are buggy), because of this we need test_strategy=standalone to run the tests locally and produce the right coverage artifacts.
- After my experimentation, coverage builds seem to be incompatible with remote_download_outputs=toplevel (or minimal) so we need to set it to remote_download_outputs=all. Otherwise, some coverage artifacts aren't present locally for the coverage report generation. This is a bug in Bazel and I'll file a bug upstream for that.
- Similar experimentation shows that remote caching is also incompatible with remote coverage. For some reason, caching makes prevents some of the coverage artifacts to be present locally and the report generation consistently fails. This is another bug from Bazel (I'll file another issue for this).

Last, I've added a remote-ci-debug config to print various different streams of data from different Bazel stages

Risk Level: Low
Testing: See coverage workflow
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: Luis Fernando Pino Duque <luis@engflow.com>
Signed-off-by: JP Simard <jp@jpsim.com>

**Description**

Previously the MCPProxy struct was create per request, which caused a
recreation of http client for example, and resulted in not reusing the
connection pool.

This did not result in a noticeable benchmark result diff but it will
improve the perf in majority of use cases.

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Co-authored-by: Ignasi Barrera <ignasi@tetrate.io>