Fix collision between macOS workflow artifacts in release workflows

[per1234]

GitHub Workflows are used to automatically generate and publish production and nightly releases of the project. This is done for a range of host architectures, including macOS. The macOS builds are then put through a notarization process in a dedicated workflow job.

GitHub Actions workflow artifacts are used to transfer the generated files between sequential jobs in the workflow. The actions/upload-artifact and actions/download-artifact actions are used for this purpose.

The workflow artifact handling had to be reworked recently in order to handle a breaking change in the 4.0.0 release of the actions/upload-artifact action (#662 / 3289cb8). Previously, a single artifact was used for the transfer of the builds for all hosts. However, support for uploading multiple times to a single artifact was dropped in version 4.0.0 of the actions/upload-artifact action. So it is now necessary to use a dedicated artifact for each of the builds. These are downloaded in aggregate in a subsequent job by using the artifact name globbing and merging features which were introduced in version 4.1.0 of the actions/download-artifact action.

A regression was introduced at that time. The chosen approach was to use a separate set of artifacts for the non-notarized and notarized files. An overview of the sequence (the prefixes are the workflow job names):

1. create-release-artifacts/create-nightly-artifacts: Generate builds.
2. create-release-artifacts/create-nightly-artifacts: Upload builds to workflow artifacts
3. notarize-macos: Download workflow artifacts.
4. notarize-macos: Notarize macOS build from downloaded artifact.
5. notarize-macos: Upload notarized build to workflow artifact with a different name than the source artifact.
6. create-release/publish-nightly: Download workflow artifacts.
7. create-release/publish-nightly: Publish builds.

The problem with this is that the artifacts for the non-notarized (uploaded by the create-release-artifacts/create-nightly-artifacts job) and notarized (created by the notarize-macos job) files are then downloaded and merged by the create-release/publish-nightly job. Since each artifact contains a file with the same path in the merged output, the contents of the last downloaded artifact overwrite the contents of the first. It happens that the non-notarized artifact is downloaded after the notarized artifact, so this file path collision results in non-notarized macOS builds being published instead of the notarized builds as intended, and as done by the workflow prior to the regression. For example, this bug was also present in the Arduino CLI repository and you can see the impact on its releases:

% wget https://downloads.arduino.cc/arduino-cli/nightly/arduino-cli_nightly-latest_macOS_ARM64.tar.gz

[...]

% tar -xf arduino-cli_nightly-latest_macOS_ARM64.tar.gz

% spctl -a -vvv -t install arduino-cli
arduino-cli: rejected

% wget https://downloads.arduino.cc/arduino-cli/arduino-cli_latest_macOS_ARM64.tar.gz

[..]

% tar -xf arduino-cli_latest_macOS_ARM64.tar.gz

% spctl -a -vvv -t install arduino-cli
arduino-cli: rejected

The chosen solution is that, instead of using new artifacts for the notarized builds, to overwrite the same macOS artifacts containing the no-notarized builds, which were generated by the create-release-artifacts/create-nightly-artifacts job with the notarized builds from the notarize-macos jobs. This is made possible by the overwriting capability of the actions/upload-artifact action (which was introduced in version 4.2.0: actions/upload-artifact@11ff42c).

An overview of the new sequence (the prefixes are the workflow job names):

1. create-release-artifacts/create-nightly-artifacts: Generate builds.
2. create-release-artifacts/create-nightly-artifacts: Upload builds to workflow artifacts
3. notarize-macos: Download macOS x86 or Apple Silicon workflow artifact.
4. notarize-macos: Notarize macOS build from downloaded artifact.
5. notarize-macos: Upload notarized build to same workflow artifact, overwriting the non-notarized contents.
6. create-release/publish-nightly: Download workflow artifacts.
7. create-release/publish-nightly: Publish builds.

The result is that there is no file path collision when the create-release/publish-nightly job downloads and merges the artifacts.