While these look nice, they require the discord workflow to sit around
and wait for the build-and-lint workflow to finish in order to get its
status which means we waste an extra workflow runner that does nothing
for each build-and-lint run.
Since some builds can take even longer than 1 hour
(for example: f033416893)
this commit just increases the timeout to be github's
own workflow timeout (effectively disabling it) and just
lets github handle it instead.
The previous filter would filter out queued checks as well, which would
result in erroneous build success notifications going out if github
started the discord notifications workflow before all other workflows.
Since our tests usually take at least 10 minutes theres no point in
checking every 10 seconds, and github was starting to complain about
the very high API usage.
It looks like some particularly long builds (After a toolchain cache
reset and on a slow worker) can take much longer than the current set
timeout of 20 minutes.
While we did allow the notify_discord job to run inside the context,
we didnt ask github to run in that context. This commit also uses the
"action-wait-for-check" sub-action to ensure the posted build results
are accurate for pull requests (since the build workflow is done in a
separate context for PRs)
