CI runs triggered by repository_dispatch get the correct SHA assigned

[mpfirrmann]

Some CI jobs that run after a push to master get triggered by a build artifact of a different job, e.g. the AGW Test LTE Integration With Bazel Debian Build runs after AGW Build, Format & Test Bazel's bazel_package job finishes. This leaves the respective overview page in the unfortunate state that it is not directly obvious, which commit corresponds to which run. This information is given by the commit SHA in each individual run. However, some runs get assigned the same SHA. See for example these two runs from Dec 22 2021:
https://github.com/magma/magma/actions/runs/3756451402
https://github.com/magma/magma/actions/runs/3756454343
On this morning, two commits were pushed: 782d907 and 0ef52a7. Both runs linked above reference commit 0ef52a7, the PR which was pushed second. There are no runs associated with the other SHA. The information is received via ${{ github.sha }}, maybe it only points to the head commit which may change before the test workflow gets triggered by the finished build.

[mpfirrmann]

Results of both linked runs:

• Run 3756451402 failed with a 6h GitHub Actions timeout.
• Run 3756454343 ran green.

Both tagged the resulting .xml's that are published to firebase with the same 0ef52a7...- SHA. See here and here.
Conclusion:
In the end, both displayed entries in the dashboard are wrong. The commit with the green tests did receive the failing reports of the timed-out tests and the commit with the timed-out tests did not receive any test verdict. Instead of one green and one red tests we see one red test and one without verdict.

[mpfirrmann]

Taking a look into documentation for the repository_dispatch workflow trigger:
GITHUB_SHA is here the "Last commit on default branch".
This means if there is a push to master while the the integ tests wait for their trigger workflow to finish, the SHA changes and is not assigned correctly. We may prevent this by parsing the SHA in the client_payload.