ci: pin flake8 builtins to avoid failing on 2.2.0 [backport 2.0] (#7472)

Backport 4e7c00a from #7466 to 2.0.

TL;DR is:
- flake8-builtin 2.2.0 was released recently, adds rule A004 for
shadowing builtins
https://github.com/gforcada/flake8-builtins/blob/main/CHANGES.rst
It's breaking pre_check for [some backport
PRs](#7418) (and I assume it
would also break builds for releases)
- Release branches (1.*, 2.0 , and 2.1) still use flake8 in CI as part
of hatch run style
- We need to either pin flake8-builtin to 2.1.0 or backport :pr: [chore:
migrate to ruff](https://github.com/DataDog/dd-trace-py/pull/6658/files)
to those branches

I started by backporting, but the conflict was pretty ugly given the
number of files changed. Therefore I propose we just merge the pin to
2.1 and backport to other versions.

## Checklist

- [x] Change(s) are motivated and described in the PR description.
- [x] Testing strategy is described if automated tests are not included
in the PR.
- [x] Risk is outlined (performance impact, potential for breakage,
maintainability, etc).
- [x] Change is maintainable (easy to change, telemetry, documentation).
- [x] [Library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html)
are followed. If no release note is required, add label
`changelog/no-changelog`.
- [x] Documentation is included (in-code, generated user docs, [public
corp docs](https://github.com/DataDog/documentation/)).
- [x] Backport labels are set (if
[applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting))

## Reviewer Checklist

- [x] Title is accurate.
- [x] No unnecessary changes are introduced.
- [x] Description motivates each change.
- [x] Avoids breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes unless absolutely necessary.
- [x] Testing strategy adequately addresses listed risk(s).
- [x] Change is maintainable (easy to change, telemetry, documentation).
- [x] Release note makes sense to a user of the library.
- [x] Reviewer has explicitly acknowledged and discussed the performance
implications of this PR as reported in the benchmarks PR comment.
- [x] Backport labels are set in a manner that is consistent with the
[release branch maintenance
policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)
- [x] If this PR touches code that signs or publishes builds or
packages, or handles credentials of any kind, I've requested a review
from `@DataDog/security-design-and-guidance`.
- [x] This PR doesn't touch any of that.

Co-authored-by: Zachary Groves <[email protected]>

Author: github-actions[bot]