Add support for python asyncio

[marctc]

This PR adds support to track context creation of python asyncio framework in order to add this information of trace context propagation.
Thanks @aabmass for the guidance.
Paired with @grcevski
Fixes #931

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 47.29%. Comparing base (891d1fd) to head (67544ed).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #966      +/-   ##
==========================================
- Coverage   47.29%   47.29%   -0.01%     
==========================================
  Files         261      261              
  Lines       27448    27472      +24     
==========================================
+ Hits        12982    12993      +11     
- Misses      13600    13611      +11     
- Partials      866      868       +2     

Flag	Coverage Δ
integration-test	22.83% <100.00%> (+0.01%)	⬆️
integration-test-arm	0.00% <0.00%> (ø)
integration-test-vm-${ARCH}-${KERNEL_VERSION}	0.00% <0.00%> (ø)
k8s-integration-test	2.65% <0.00%> (+<0.01%)	⬆️
oats-test	0.00% <0.00%> (ø)
unittests	48.48% <0.00%> (-0.07%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[grcevski]

@marctc, I think what would really help is some simple diagram showing what happens at what point and how do we track the context, or an explanation step by step. The reason that I'm confused is that the original logs shown by the bpftrace program that Aaron wrote, things are not the same here in this implementation.

What I understood from those logs is that:

1. CopyCurrent runs on the server (parent) thread and sets up a copy of the context for the async task. This is the place where we would search in server_traces to pull the current trace information for the async tasks.
2. run_context happens on all async tasks, server or client, but the ones we care about is the client tasks. The context found in run_context on the client task should match the context setup in 1. by copy current. So if we recorded information in the parent task for the context pointer, we should be able to find the trace parent tp_info_t for the client when we end up in trace_common looking up the context.

[grcevski]

Can you modify these tests to run simultaneous requests in parallel, like testHTTPTracesNestedNginxSQL or testHTTPTracesNestedNginx in red_test_ruby.go. This will ensure that the context matching truly works even when there are multiple requests in play.

Same for testPythonAsyncToThread.

[fstab]

Both endpoints (/sequential and /to-thread) run client requests sequentially: The await suspends the main thread until the client call is done, only then the next client call is scheduled.

It might be good to have a test that actually runs multiple requests in parallel.