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):