chore: prevent CI double runs on push + pull_request

[mistercrunch]

SUMMARY

I noticed recently that we get many "double-triggers" of CI actions on some PRs, most notable on PRs opened from the main apache repo, triggering against the master branch (see screenshot bellow). This is typically one for the push action and one for the pull_request action, running effectively the exact same CI script twice. Note that I think the double triggers also on forks (I'd have to double check), but just doesn't show under the PR list of required CI steps, and is probably just associated with the fork of the user.

Anyhow, so I went through all the githbub workflows and applied more restrictions. In most cases we apply the main pattern:

on:
  push:
    branches:
      - 'master'
  pull_request:
    types: [synchronize, opened, reopened, ready_for_review]

This will trigger for each change on the pull request, and for every commit as it merges on the master branch.

In some other cases, I added a paths statement where I knew we should only run a workflow given a certain obvious folder, like frontend tests should only run if we touch superset-frontend/** and such.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (c2ab9bb) 69.29% compared to head (26ca7a8) 67.16%.
Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #26766      +/-   ##
==========================================
- Coverage   69.29%   67.16%   -2.13%     
==========================================
  Files        1894     1894              
  Lines       74173    74175       +2     
  Branches     8243     8243              
==========================================
- Hits        51396    49821    -1575     
- Misses      20708    22285    +1577     
  Partials     2069     2069              

Flag	Coverage Δ
mysql	77.93% <ø> (-0.03%)	⬇️
postgres	78.06% <ø> (?)
python	78.20% <ø> (-4.41%)	⬇️
sqlite	77.64% <ø> (?)
unit	?

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.

[betodealmeida]

[betodealmeida]

Should we add a path here, eg:

Suggested change

	types: [synchronize, opened, reopened, ready_for_review]
	paths:
	- "superset-frontend/src/**"
	types: [synchronize, opened, reopened, ready_for_review]

[mistercrunch]

I ended up squeezing in more cache optimizations for docker in there as I was testing all sorts of things to speed up the builds:

• I got the docker buildx --cache-from and --cache-to to actually work with remote registry, no exactly sure why it didn't work before, something about using a different repo helped here
• disabled some slow builds in the matrix for py39/arm combo, where there's some wheels to build from scratch and QEMU (the arm emulator used here) is super slow, we can bring them back if needed, now that we cache things it should be fast unless a python dependency changes
• I did disable some tests, so that say frontend unit tests only run if the frontend changes, or some python checks (tests, lint, ..) only runs if the python package changes, ... but those tests were marked as required, which GitHub is a bit stupid about. If you try to skip a required test, the PR hangs forever. So I found a workaround that I documented around no-op.yml workflow for those edge cases. There were other workarounds, but this one seemed best