Move Actions concurrency limits to the build step

[strugee]

What type of PR?

Enhancement

What does this PR do?

This lays the groundwork for a cron workflow to rebuild nightly in order to get security updates. I considered trying to just add a schedule trigger to multiarch.yml, but schedule only supports the default branch as github.ref which gets irritating because anywhere that uses github.ref now has to fall back to another value if the workflow was triggered by a schedule. It's much easier to just add another workflow and

Note that there is technically now a race here because GitHub doesn't guarantee ordering of jobs within a concurrency group, so in theory if commit B got merged very shortly after commit A, and commit B's multiarch run was super slow for some reason, commit A might end up preempting it. However AFAICT this is basically impossible in practice because Bors will properly serialize merges. This is the reason we remove concurrency control from multiarch.yml.

I enabled cancel-in-progress since it just kinda seemed like we might as well - if we let the build finish, it'll just be overwritten in a few minutes anyway.

Related issue(s)

None AFAIK

Prerequisites

Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.

• In case of feature or enhancement: documentation updated accordingly
• Unless it's docs or a minor change: add changelog entry file.

[mergify]

Thanks for submitting this pull request.
Bors-ng will now build test images. When it succeeds, we will continue to review and test your PR.

bors try

Note: if this build fails, read this.

[bors-mailu]

try

Build succeeded:

• CI-Done

[strugee]

Note that I'm not fully sure that this is the right concurrency declaration because the docs are totally wrong. See github/docs#31988

[Diman0]

This does not fit with our workflow. Builds should only be triggered by pull requests. We also make use of pinned dependencies to ensure that a rebuild always has the same result and never results in a broken built.
The same applies for alpine. For alpine we use a static image which is manually updated when needed. At that moment we also test if the updated alpine image introduces breaking changes.