Move python/poetry/dependency steps to a composite action

[briantist]

Right now there are several steps we repeat within our GitHub workflows for setting up the environment, like:

• install python
• install poetry
• install dependencies
• dependency caching

It's a lot of repetition that needs to be done in nearly every job across several workflows, and whenever anything changes, it needs to be done in several places.

Caching deserves its own explanation first.

Dependency caching

Right now we use the setup-python action's support for caching dependencies.

It's simple, but it has few customization options, and several quirks.

Here are the current set of issues we face:

• We recently (Drop Python 3.6 & 3.7, Add Python 3.11, bump some dependencies #1048) properly split out dev dependencies and made them optional, and this means our build jobs no longer need to install all the dev dependencies just to build the package.
  • However, the cache keys are not customizable with this method, and it resulted in the cache being saved which didn't include dev dependencies, which caused the lint & test jobs to fail when they restored that cache
  • We could attempt to install dependencies when cache restore is successful anyway, and maybe we should, but that would have masked this particular problem and caused slower runs
• setup-python when set to use a cache mode of poetry must have poetry installed before running it so that it can read the configuration
  • but this is awkward then because poetry might not be installed for the version of python we want to use
• currently we cannot use caching at all on Windows runners because the setup-python action can't seem to find the poetry binary
  • that might be related to the above bullet, due to pathing and such, but not certain
  • we can't do anything to tell the action where to find poetry either, so we're stuck in the current configuration

Resolving caching issues

It's certainly possible for us to address some of the caching issues by doing the caching ourselves with actions/cache (and the new cache-save and cache-restore actions), but that will add several steps to all the workflows, near the beginning and probbaly near the end. We will need to reimplement some of the logic in the action on what to cache and when.

This will add even more to these boilerplate setup steps making our workflows harder to read and reason about.

Proposal

We can create a composite action in the repository that takes the minimal inputs we need, and performs these things for us.

By wrapping the logic here, the main workflows can boil this down to single step.

We would take inputs for things like python version, poetry version, dependency group(s?), and handle the setup of the pieces, the caching logic, OS differences, etc.