Set up contract tests

[thpierce]

In this commit, we are setting up contract tests similar to those in the aws-otel-java-instrumentation repo. Initially, we are just commiting the logic to run the mock collector and a single application that uses the requests library, but the tests are extensible to other frameworks.

There are a number of small differences between these tests and the Java contract tests, most of which are language dependent.

Callouts:

• I've disabled code style checks on three files: mock_collector_service_pb2_grpc.py, mock_collector_service_pb2.py, andmock_collector_service_pb2.pyi. These are generated GRPC files and no edits to these files are recommended after generating from proto files. I have made no edits to these files after generating with commands described in the mock collector README.
• requests_server.py is based on the native-http-client/App.java
• mock_collector_client.py is based on the MockCollectorClient.java and ResourceScopeSignal.kt. Note that a lot of the serialization/deserialization logic is simplified in Python/gRPC.
• mock-collector classes (e.g. mock_collector_server, mock_collector_metrics_service, etc are based on the mockcollector java classes. Callout that java uses an HTTP server wrapping gRPC servicers, while I'm just using a gRPC server and servicers as it was simpler to do so in Python.
• app_signals_constants.py note that metric names are all lowercase, which is intentional (java will be fixed in future).
• contract_test_base.py is based on ContractTestBase.java. One substantial difference is that we are not passing information in about the agent, since both testcontainers and OTEL instrumentation mechanisms are quite different in Java vs Python.
• requests_test.py is based on BaseHttpClientTest.java and NativeHttpClientTest.java
  • Note that PEER_SERVICE does not appear to be supported by Python
  • Note that OTEL does not instrument basic HTTP Servers, so there are no server spans produced by the application and only client spans are produced requests. This is acceptable from a contract perspective, but does result in AWS_LOCAL_OPERATION being InternalOperation and AWS_SPAN_KIND being LOCAL_ROOT on spans/metrics (in metrics AWS_SPAN_KIND is CLIENT, this is expected)
  • Note that NET_PEER_NAME and NET_PEER_PORT are not populated by requests instrumentation, which appears to be an upstream bug. This results in AWS_REMOTE_SERVICE being UnknownRemoteService
• pylint: disable summary:
  • invalid-name - only used where I do not have control over the method name (e.g. overrides)
  • broad-exception-caught - Used where we really do want to just catch everything and keep going
  • no-self-use - only used when defining methods that are designed to be overridden by subclasses.
  • no-member - Used for Span.SPAN_KIND_CLIENT - for some reason, pylint cannot detect this constant, likely related to gRPC/proto magic

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[srprash]

TBH, I did not understand much of the protobuf stuff in the mock collector but I guess if it is working fine then all that must be correct. 😄
Other than that did a sanity check on the code and posted comments/questions wherever I needed clarification. Overall LGTM!

[srprash]

LGTM!

[XinRanZhAWS]

Not blocking: you mentioned an example application need a pyproject.toml, but your request application don’t contain this. It may be because of this application is too simple, so not blocking anything

[thpierce]

@XinRanZhAWS thanks for the reminder, I had it initially, then removed it because I forgot why I had it in the first place. Good thing I wrote it down, and good thing you reviewed haha. Will add back.

[XinRanZhAWS]

LGTM, thanks