chore: expand ruff rule sets and make corresponding minor adjustments

[tonyandrewmeyer]

This PR enables a few additional ruff checks - since they are bundled with ruff and ruff is extremely fast, they are basically free. I cherry-picked the set that I agree with/like the most - I'm happy to argue for the inclusion of any specific ones where you disagree, or consider other rules if you have preferences.

• pyupgrade (UP) - I love this tool - I find it's a super easy way to adopt new features as you move up your minimum-supported Python version (in using it for a year or so I haven't ever had it suggest something that I didn't like)
• flake8-2020 (YTT)
• bandit (S) - a good tool for avoiding accidentally missing things, in my opinion (marking them with noqa shows that thought has gone into it, which has value in itself)
• flake8-bugbear (B)
• flake8-simplify (SIM)
• Ruff specific (RUF) - seems like we should since we're using the tool
• perflint (PERF) - seems to make good suggestions in general

Notes:

Where the linter picks up new issues, these are handled in one of these ways:

• Ignore with a noqa: directive if it's a false positive or should otherwise be permanently ignored in that specific case
• Ignore for a file or group of files (the docs and tests have several of these) where it's something we want to pick up in the core code but not everywhere
• Ignore with a note to review later when it's likely that there would be too much additional noise in this PR
• Make the recommended change, when it's small and seems reasonable

Continues from #1102.

[benhoyt]

Thanks! Left a few initial comments.

[tonyandrewmeyer]

One option here would be to split this into two PRs, one that has all the changes outside of pyproject.toml (and the noqa's, I guess) and then a second one that has the pyproject.toml and noqa changes, and also adds the previous commit to a .git-blame-ignore-revs file. Do you think that would be preferable? None of the code changes are functional ones, although some should be (insignificant) performance improvements.

[benhoyt]

Looks great to me, just the few things we discussed.

[benhoyt]

At first I think we should disable this one, but looking over the PR I think it's almost always an improvement, so this seems reasonable to keep enabled.

[tonyandrewmeyer]

One option here would be to split this into two PRs, one that has all the changes outside of pyproject.toml (and the noqa's, I guess) and then a second one that has the pyproject.toml and noqa changes, and also adds the previous commit to a .git-blame-ignore-revs file. Do you think that would be preferable? None of the code changes are functional ones, although some should be (insignificant) performance improvements.

We briefly discussed this and decided that it's not worth it for this PR.