Replace styfle/cancel-workflow-action with new GitHub concurrency: standard

[vorburger]

See https://github.com/styfle/cancel-workflow-action/blob/main/README.md (and go/github-actions#cancel-workflows)

I've intentionally raised this separately from #2313 (which is included here) and #2314 (which builds on this) to make it easier to review, and revert in case it's needed because this unexpectedly breaks anything (which it should not).

This should be rebased after #2313 is merged.

[vorburger]

Kokoro: Build and Device Tests — Kokoro build failed. Check logs for details.

due to #2297

[vorburger]

Kokoro: Build and Device Tests — Kokoro build failed. Check logs for details.

OMG, it's #1482 again... how about we just do #2318 at this point?

[jingtang10]

if the run_id is included here in the group id, does this not mean that each run will have a separate group id? and does that mean previous runs will not be cancelled?

actually, if the head_ref is part of this, how would cancellation even help anything? shouldn't we cancel jobs that are in the same branch? i.e. if you push a new commit we should cancel the previous job?

[vorburger]

I now had a closer look at related docs about this (e.g. https://docs.github.com/en/actions/using-jobs/using-concurrency and https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) and, as far as I understand it, believe this to be correct as-is, because:

• those || are fallback values (not "concatenations") so my understanding is that e.g. the run_id would not be included as long as a head_ref or else ref was non-NIL
• the head_ref is (quote) "the source branch of the pull request in a workflow run" - which will (should, based on doc) cancel jobs that are in the same branch - I think? But note that, quote: "This property is only available when the event that triggers a workflow run is either pull_request or pull_request_target." ...
• ... so the ref is a fallback to (quote) "(...) For workflows triggered by push, this is the branch or tag ref that was pushed (...) " From the doc it seems like it may actually be sufficient to use only this, but given that http://go/github-actions#cancel-workflows suggests to use the combination, I went with that; I suspect it can't harm to be double extra safe
• lastly, the run_id is a last fallback is something I thought I saw on some example yesterday. I'm not sure if this will be used, but given that ref docs says that it's "only set if a branch or tag is available for the event type" it seems like a sensible pre-caution as a last resort? I can also remove it, if you think it's confusing?

[jingtang10]

thanks michael for the explanation.

this is clear to me now.

up to you about the run_id. but either way can we add a single line of comment to explain what's happening here? doesn't have to go to the length of your comment above, but just noting that we're using the branch/pr ref etc so possible to cancel previous runs.

[jingtang10]

once addressed please feel free to merge.

[vorburger]

Removed github.run_id and added inline documentation comments; I will self merge when build is green.

[vorburger]

FTR: I "tested" this by clicking the Update Branch button, and seeing https://github.com/google/android-fhir/actions/runs/6696513296 got cancelled.

I'm going to merge this now, without waiting for Kokoro, because this is a GitHub-Action-only change, which cannot impact Firebase Test Lab runs (so Kokoro's result is irrelevant in this particular case).