chore: 2nd try - simplify python dependencies

[mistercrunch]

Keeping some of the good ideas from #27465 while putting that one on hold.

What's happening in this PR?

• keep pip-compile-multi, but go down to two bundles base.in and development.in, converging all of testing.in, docker.in, integration.in and local.in into development.in
• create a github reusable action .github/actions/setup-backend/action.yml for python/backend setup

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.62%. Comparing base (16fcdb1) to head (731d5fd).
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #27505      +/-   ##
==========================================
+ Coverage   67.39%   69.62%   +2.23%     
==========================================
  Files        1909     1909              
  Lines       74736    74739       +3     
  Branches     8326     8326              
==========================================
+ Hits        50368    52040    +1672     
+ Misses      22318    20649    -1669     
  Partials     2050     2050              

Flag	Coverage Δ
mysql	78.02% <ø> (+0.01%)	⬆️
postgres	78.14% <ø> (-0.01%)	⬇️
python	82.91% <ø> (+4.62%)	⬆️
sqlite	77.57% <ø> (-0.01%)	⬇️
unit	56.65% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[craig-rueda]

LGTM

[eschutho]

LGTM. But do we know if this could potentially break someone's deployment if they were relying on the dev dependencies for production? I'm thinking maybe the bigquery or oauth drivers.

[mistercrunch]

I added a note in UGPRADING.md, but would love to get @john-bodley 's blessing before merging this one

[eschutho]

Great, or rather, even with the notes in UPGRADING.md, would this break semver if this is released in 4.1 for example?

[mistercrunch]

I don't think we should treat requirements/* as a public interface. Maybe, just maybe, we should treat requirements/base.txt as sensitive (renaming/deleting is would likely break some things somewhere).

I could be great to define the things or type of things we want to treat as a public interface for semver purposes and beyond. I'd argue that pinned deps shouldn't make that list.

Now with the pinned reqs keeping the package together that's a bit different, though that's why I'm trying to get back to a place where the pinned requirements would not be vital.

[mistercrunch]

Ok, merging this as I have other improvements lined up