I think we may also want to run this by ProdSec since I'm not sure whether they'll have an opinion on automated commits being made to the repo

I am working on it. Prodsec doesn't see the problem, but I have yet to confirm this with CorpSec, which manages the Github infra.

I have approvals from the corp sec team and the prod sec team for this change. RA is not needed.

Thanks for taking this on, @sfc-gh-kbregula! A couple nits:

1. I think informative PR descriptions are always important - but especially on PRs that change a lot of code and have an impact on workflows. (I'm not a fan of our PR template - it makes for very low signal:noise descriptions - and I advocate just using it as a guideline ("make sure you at least include XYZ bits of data"), instead of as a literal template.) For this particular PR, I'd love to see the template thrown out and replaced with a description of what changes are included, and why they are important to us, so that future readers can understand the context.

@sfc-gh-tteixeira writes amazing PR descriptions - see #5857 for the gold standard. (We definitely don't need all PR descriptions to be this thorough, but it's a good north star to aim for!)

2. I think we're missing a lot of valuable documentation in the code itself. In particular,

• the build_info.py script is a pretty big chunk of code, but it's not clear at a glance what it is doing and why it is useful. A docstring/comment at the top of the file saying "here's what this does and here's where it's used" would go a long way. I think it'd also be great to get docstrings for most of its functions. should_test_all_python_versions - what's its purpose, and when does it return True? What are the "output variables" in get_output_variables? Why do we save the environment variables we do, and who uses them?
• The PR removes the set_python_versions/action.yml file, which had a short, simple, understandable description. There's a lot of new Github actions code (especially in python-versions.yml) that doesn't contain descriptions of what it's doing (and why), and as a result it's harder to follow.

We don't need to document literally everything we do - sometimes code really is simple and short enough that you can understand it without additional docstrings or comments. But in general, I prefer over-documenting to under-documenting; it makes life easier for coworkers, and also for the future versions of ourselves who may have forgotten the whats and whys of the code when we revisit it months or years later :)

@tconkling Thanks for the review. I added more documentation and updated the PR description to add more context to this change.