fix(docs): also consider tag refs for identifying docs version (DataD…

…og#3855) (DataDog#3858)

## Description

Since we created the v1.2.0 tag on a commit that wasn't the HEAD of the 1.2 branch
we were never able to find a refs/remote/origin/1.2 associated with the commmit.
This caused us to keep going back in the history until we grabbed v0.27 as the max version,
which is too old for automated release notes, and we ended up with empty release notes.

With this change, we will consider refs/tags/vx.y.z[rc#] as well refs/remote/origin/
when looking for the current version to determine what versions to generate notes for.

As before, for dev branches (1.x) we will use the next major as the cutoff. For release branches
(1.2) or any tags (v1.2.0, v1.2.1rc1, etc) we will use the next minor version.

## Checklist
- [x] Title must conform to [conventional commit](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional).
- [x] Add additional sections for `feat` and `fix` pull requests.
- [x] Ensure tests are passing for affected code.
- [ ] [Library documentation](https://github.com/DataDog/dd-trace-py/tree/1.x/docs) and/or [Datadog's documentation site](https://github.com/DataDog/documentation/) is updated. Link to doc PR in description.

## Relevant issue(s)

Fixes DataDog#3853

## Testing strategy
I have verified that running this locally properly generates the correct release notes for the `v1.2.0` tag.

From read the docs logs:

```
reading sources... [ 73%] release_notes
capping max report version to <Version('0.27')>
skipping 1.2 >= 0.27
skipping 1.1 >= 0.27
skipping 1.0 >= 0.27
```

Locally:

```
capping max report version to <Version('1.3.0')>
scanning /Users/brett.langdon/datadog/dd-trace-py/releasenotes/notes for origin/1.2 release notes, stopping at v1.2.0
unable to find release notes file associated with unique id '93288688036f669f', skipping
unable to find release notes file associated with unique id '59eedcbbcf065204', skipping
got versions ['v1.2.1rc1', 'v1.2.0']
scanning /Users/brett.langdon/datadog/dd-trace-py/releasenotes/notes for origin/1.1 release notes, stopping at v1.1.0
unable to find release notes file associated with unique id '59eedcbbcf065204', skipping
got versions ['v1.1.4', 'v1.1.3', 'v1.1.2', 'v1.1.1', 'v1.1.0']
```

## Reviewer Checklist
- [x] Title is accurate.
- [x] Description motivates each change.
- [x] No unnecessary changes were introduced in this PR.
- [x] PR cannot be broken up into smaller PRs.
- [x] Avoid breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes unless absolutely necessary.
- [x] Tests provided or description of manual testing performed is included in the code or PR.
- [x] Release note has been added for fixes and features, or else `changelog/no-changelog` label added.
- [x] All relevant GitHub issues are correctly linked.
- [ ] Backports are identified and tagged with Mergifyio.
- [ ] Add to milestone.

(cherry picked from commit 34095ca)

Co-authored-by: Brett Langdon <[email protected]>

fix(asgi, starlette, fastapi): exclude background task durations from…

… web requests (backport DataDog#3799) (DataDog#3840)

This is an automatic backport of pull request DataDog#3799 done by [Mergify](https://mergify.com).


---


<details>
<summary>Mergify commands and options</summary>

<br />

More conditions and actions can be found in the [documentation](https://docs.mergify.com/).

You can also trigger Mergify actions by commenting on this pull request:

- `@Mergifyio refresh` will re-evaluate the rules
- `@Mergifyio rebase` will rebase this PR on its base branch
- `@Mergifyio update` will merge the base branch into this PR
- `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch

Additionally, on Mergify [dashboard](https://dashboard.mergify.com/) you can:

- look at your merge queues
- generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com
</details>

fix(redis): alias format_command_args (DataDog#3822) (DataDog#3823)

DataDog#3299 moved a utility function in the redis integration as part of a refactoring. This breaks the library's versioning policy for a minor release. We add back this function as an alias to the new function.

## Checklist
- [ ] Library documentation is updated.
- [ ] [Corp site](https://github.com/DataDog/documentation/) documentation is updated (link to the PR).

## Reviewer Checklist
- [ ] Title is accurate.
- [ ] Description motivates each change.
- [ ] No unnecessary changes were introduced in this PR.
- [ ] PR cannot be broken up into smaller PRs.
- [ ] Avoid breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes unless absolutely necessary.
- [ ] Tests provided or description of manual testing performed is included in the code or PR.
- [ ] Release note has been added for fixes and features, or else `changelog/no-changelog` label added.
- [ ] All relevant GitHub issues are correctly linked.
- [ ] Backports are identified and tagged with Mergifyio.
- [ ] Add to milestone.

(cherry picked from commit 77d3a2d)

Co-authored-by: Tahir H. Butt <[email protected]>

fix(redis): alias format_command_args (DataDog#3822) (DataDog#3823)

DataDog#3299 moved a utility function in the redis integration as part of a refactoring. This breaks the library's versioning policy for a minor release. We add back this function as an alias to the new function.

## Checklist
- [ ] Library documentation is updated.
- [ ] [Corp site](https://github.com/DataDog/documentation/) documentation is updated (link to the PR).

## Reviewer Checklist
- [ ] Title is accurate.
- [ ] Description motivates each change.
- [ ] No unnecessary changes were introduced in this PR.
- [ ] PR cannot be broken up into smaller PRs.
- [ ] Avoid breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes unless absolutely necessary.
- [ ] Tests provided or description of manual testing performed is included in the code or PR.
- [ ] Release note has been added for fixes and features, or else `changelog/no-changelog` label added.
- [ ] All relevant GitHub issues are correctly linked.
- [ ] Backports are identified and tagged with Mergifyio.
- [ ] Add to milestone.

(cherry picked from commit 77d3a2d)

Co-authored-by: Tahir H. Butt <[email protected]>

fix: fix install requires python_version constraint for protobuf (bac…

…kport DataDog#3805) (DataDog#3821)

This is an automatic backport of pull request DataDog#3805 done by [Mergify](https://mergify.com).
Cherry-pick of 9d76e3b has failed:
```
On branch mergify/bp/1.2/pr-3805
Your branch is up to date with 'origin/1.2'.

You are currently cherry-picking commit 9d76e3b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   setup.py

no changes added to commit (use "git add" and/or "git commit -a")
```


To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

---


<details>
<summary>Mergify commands and options</summary>

<br />

More conditions and actions can be found in the [documentation](https://docs.mergify.com/).

You can also trigger Mergify actions by commenting on this pull request:

- `@Mergifyio refresh` will re-evaluate the rules
- `@Mergifyio rebase` will rebase this PR on its base branch
- `@Mergifyio update` will merge the base branch into this PR
- `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch

Additionally, on Mergify [dashboard](https://dashboard.mergify.com/) you can:

- look at your merge queues
- generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com
</details>

ci: fix ddtest on != CircleCI (DataDog#3787)

If the script is used on something else than CircleCI, then the test return
`false` and `set -e` makes the script exit with 1, therefore never running
docker-compose.

It would also passe "" as an argument to docker-compose making it fail.

The --quiet-pull does not exist (at least on Docker Desktop) so avoid using it
if not in CircleCI.

fix: pin protobuf to version 3 due to incompatibility with 4 (DataDog…

…#3766) (DataDog#3771)

Latest release of [protobuf](https://pypi.org/project/protobuf/) breaks profiling with

```
Traceback (most recent call last):
  File "/usr/src/app/main.py", line 619, in <module>
    import ddtrace.profiling.auto  # noqa
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/__init__.py", line 5, in <module>
    from .profiler import Profiler  # noqa:F401
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/profiler.py", line 26, in <module>
    from ddtrace.profiling.exporter import file
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/exporter/file.py", line 6, in <module>
    from ddtrace.profiling.exporter import pprof
  File "ddtrace/profiling/exporter/pprof.pyx", line 33, in init ddtrace.profiling.exporter.pprof
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/exporter/pprof_pb2.py", line 38, in <module>
    _descriptor.FieldDescriptor(
  File "/usr/local/lib/python3.9/site-packages/google/protobuf/descriptor.py", line 560, in __new__
    _message.Message._CheckCalledFromGeneratedFile()
TypeError: Descriptors cannot not be created directly.
If this call came from a _pb2.py file, your generated code is out of date and must be regenerated with protoc >= 3.19.0.
If you cannot immediately regenerate your protos, some other possible workarounds are:
 1. Downgrade the protobuf package to 3.20.x or lower.
 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use pure-Python parsing and will be much slower).

More information: https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
```

## Checklist
- [ ] Library documentation is updated.
- [ ] [Corp site](https://github.com/DataDog/documentation/) documentation is updated (link to the PR).

## Reviewer Checklist
- [x] Title is accurate.
- [x] Description motivates each change.
- [x] No unnecessary changes were introduced in this PR.
- [x] PR cannot be broken up into smaller PRs.
- [x] Avoid breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes unless absolutely necessary.
- [x] Tests provided or description of manual testing performed is included in the code or PR.
- [x] Release note has been added for fixes and features, or else `changelog/no-changelog` label added.
- [x] All relevant GitHub issues are correctly linked.
- [x] Backports are identified and tagged with Mergifyio.
- [x] Add to milestone.

(cherry picked from commit da802a7)

Co-authored-by: Alexandre Fonseca <[email protected]>

fix: pin protobuf to version 3 due to incompatibility with 4 (DataDog…

…#3766) (DataDog#3770)

Latest release of [protobuf](https://pypi.org/project/protobuf/) breaks profiling with

```
Traceback (most recent call last):
  File "/usr/src/app/main.py", line 619, in <module>
    import ddtrace.profiling.auto  # noqa
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/__init__.py", line 5, in <module>
    from .profiler import Profiler  # noqa:F401
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/profiler.py", line 26, in <module>
    from ddtrace.profiling.exporter import file
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/exporter/file.py", line 6, in <module>
    from ddtrace.profiling.exporter import pprof
  File "ddtrace/profiling/exporter/pprof.pyx", line 33, in init ddtrace.profiling.exporter.pprof
  File "/usr/local/lib/python3.9/site-packages/ddtrace/profiling/exporter/pprof_pb2.py", line 38, in <module>
    _descriptor.FieldDescriptor(
  File "/usr/local/lib/python3.9/site-packages/google/protobuf/descriptor.py", line 560, in __new__
    _message.Message._CheckCalledFromGeneratedFile()
TypeError: Descriptors cannot not be created directly.
If this call came from a _pb2.py file, your generated code is out of date and must be regenerated with protoc >= 3.19.0.
If you cannot immediately regenerate your protos, some other possible workarounds are:
 1. Downgrade the protobuf package to 3.20.x or lower.
 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use pure-Python parsing and will be much slower).

More information: https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
```

## Checklist
- [ ] Library documentation is updated.
- [ ] [Corp site](https://github.com/DataDog/documentation/) documentation is updated (link to the PR).

## Reviewer Checklist
- [x] Title is accurate.
- [x] Description motivates each change.
- [x] No unnecessary changes were introduced in this PR.
- [x] PR cannot be broken up into smaller PRs.
- [x] Avoid breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes unless absolutely necessary.
- [x] Tests provided or description of manual testing performed is included in the code or PR.
- [x] Release note has been added for fixes and features, or else `changelog/no-changelog` label added.
- [x] All relevant GitHub issues are correctly linked.
- [x] Backports are identified and tagged with Mergifyio.
- [x] Add to milestone.

(cherry picked from commit da802a7)

Co-authored-by: Alexandre Fonseca <[email protected]>

fix(profiling): do not clear thread-loop link too often (DataDog#3668) (

DataDog#3713)

The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a
task is resolved, which can be up to 100 times a second. This is way too much
and we don't expect for the thread->loop mapping to change that often.

Instead we often try to clear the mapping when a new loop is attached to a
thread. In a regular application, this is the expected workflow: a thread
appears and gets a new loop, so we clear the old ones.

The worst case scenario would be an app spawning 100 threads with 100 loops and
then not doing that ever again, which would make the profiler keep a reference
on the 100 loops — until a new loop is attached, which if never, would kept the
reference forever.

Since this far from being a common pattern, it should be safe to switch to a
simpler model like this.

(cherry picked from commit f583fec)

Co-authored-by: Julien Danjou <[email protected]>
Co-authored-by: Gabriele N. Tornetta <[email protected]>

ci: retry docker pulls if fails (backport DataDog#3697) (backport Dat…

…aDog#3727) (DataDog#3732)

This is an automatic backport of pull request DataDog#3727 done by [Mergify](https://mergify.com).


---


<details>
<summary>Mergify commands and options</summary>

<br />

More conditions and actions can be found in the [documentation](https://docs.mergify.com/).

You can also trigger Mergify actions by commenting on this pull request:

- `@Mergifyio refresh` will re-evaluate the rules
- `@Mergifyio rebase` will rebase this PR on its base branch
- `@Mergifyio update` will merge the base branch into this PR
- `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch

Additionally, on Mergify [dashboard](https://dashboard.mergify.com/) you can:

- look at your merge queues
- generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com
</details>