fix(aiohttp): Remove strong reference to response object on callback (#8108)

[seandstewart]

The previous implementation added a lambda which held a reference to the response object to the request task, creating a strong reference to the request object which could lead to a memory leak, because the request and response cannot be garbage collected until the task itself is.

This reworks the middleware to store the request span in a context var and use only that context var for the task callback, ensuring that the request and response objects can be freed from memory even if the underlying task has not been garbage collected.

I haven't been able to get my local environment working correctly, so I have not been able to test this behavior to ensure correctness.

Attempts to resolve #8108

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy

[seandstewart]

Failed test is for the botocore integration, which was not impacted by this change.

[seandstewart]

I vendored and deployed this change to an application in my organization. The purple line is ddtrace's current implementation, the yellow is the implementation in this MR.

As you can see, the memory increases linearly in the current version in this library, but stabilizes in this proposed change.

Additionally, you can see the pending GC count increases linearly without this change, but resets periodically with the change, indicating the current version does block garbage collection (the drops in the purple line are when the app is rolled to the new version):

[wantsui]

Hi @seandstewart, thanks for contributing this PR!

Just as a heads up, I'm duplicating this PR so the rest of the test suite runs: #11611 ! I'm also reviewing this PR to get this merged in.

[chamini2]

Hi @seandstewart, very thankful for you to take the time to do this. Do you have any time to make tests pass so we can try to get this merged? We have been having memory leak issues for a while now.

Let me know if I can help in any way to get this done.

[seandstewart]

Hi @seandstewart, very thankful for you to take the time to do this. Do you have any time to make tests pass so we can try to get this merged? We have been having memory leak issues for a while now.

Let me know if I can help in any way to get this done.

Hey @chamini2 - see @wantsui's comment above. I am not a DataDog employee, just a contributor. They have opened their own PR with my changes and are working on that.

[sanchda]

Looks like this was duplicated in #11611. I'm going to go ahead and close this out, but the author's code changes are being taken. Thank you very much for the contribution!!

[wantsui]

Just a heads up that I closed the cloned version of this PR in favor of @ZStriker19 's #12081 .