ci: refactor and add arm64 build

[k3rnelpan1c-dev]

Description

This PR aims to provide arm64 builds in the form of per-compiled binary archives as well as a published container image as part of a container manifest.
Alongside that the Container image was altered to allow the direct deployment to a restrictive container runtime (i.e. OpenShift, which starts pods by default with an arbitrary UID and GID 0).
Finally, this PR migrates the use of some ("currently") unmaintained and archived GitHub Actions to maintained alternatives.

In case there are any questions and or necessary changes then please let me know so I can answer or fix them as soon as I can.

Motivation

During the last week (log4shell hell) I stumbled over the dependency-track project and implicitly found this project too. I wanted to help out and contribute in the area I am most active in (i.e. CI and Container) and took on the task of not only adding a arm64 build, refactoring and cleaning up the the CI and enabling the App container image to be run in an restrictive environment.

Changes

• slight refactor / reword .Net test workflow
• overhaul release workflow
  • add arm64 binary and container build
  • add musl binary build (up 4 discussion)
  • migrate Archived GitHub Actions to maintained ones
  • add checksums for Binary archives attached to GH Releases
• update Container image to permit unprivileged execution (i.e. OpenShift deployments)

Issues

• Add support for arm64 processors #67

Test run:

• the now renamed test CI: .Net CI
• the new release CI: Release
  • what a releas using the new CI looks like: https://github.com/k3rnelpan1c-dev/cyclonedx-bom-repo-server/releases
  • what the container image manifests look like https://quay.io/repository/k3rnel-pan1c/cyclonedx-bom-repo-server?tab=tags

All tests where conducted on my forks ci/refactor-test branch since I needed to redirect the outputted images to a registry I could push to, yet that branch is just one commit ahead of this branch to do exactly this redirect. (*before I realized I forgot to sign the commits and to spot a missed out repo designation, yet the logic is still the same where it counts)

WARNING I am not 100% sure the arm64 container image works as I went of the assumption that dotnet publish is smart enough to detect the proper CPU arch within the multi stage build, which the Microsoft documentation lead me to believe should be the case.

framework-dependent executable for the current platform. - dotnet publish

[k3rnelpan1c-dev]

Since I just realized that I am not 100% following the Git commit guidelines, let me know and I shall fix them in no time. Sorry for that mishap, not used to capitalized git commits 😅

[k3rnelpan1c-dev]

Suggested change

	REPO__DIRECTORY=Repo \
	REPO__DIRECTORY=/repo \

I would like to propose changing the default REPO_DIRECTORY for the container to a actual path that is also used within the usage sections and makes sense over the 'default' value that would be assumed for REPO__DIRECTORY is just a relative path.

[coderpatros]

That change makes sense. I'll have to remember to communicate it though as it could be breaking for some folks with this already deployed.

[k3rnelpan1c-dev]

While this sure can have breaking effects, I would guess the default Port change to 8080 would be the more significant breaking change 🤔

[coderpatros]

Thanks heaps for this PR. I'm on holidays at the moment and working on some stuff for CycloneDX v1.4. So it might take me a little while to review this. But this is a much appreciated contribution.

[k3rnelpan1c-dev]

Thanks heaps for this PR. I'm on holidays at the moment and working on some stuff for CycloneDX v1.4. So it might take me a little while to review this. But this is a much appreciated contribution.

Hey, first of all thank you for your reply!
No worries, I will be available as soon as you have time to review this 🙂.
Until then I may think of other things I have not thought off when setting this up and fixing or taking note of it in the forms of comments. (hope that is okay)

Enjoy your holidays and a happy new year 🎆

[coderpatros]

I really like these changes. My only concern is the use of unofficial actions for creating a GitHub release and uploading release assets.

I'm absolutely dumbfounded that GitHub is no longer maintaining official actions for these. This is such a great opportunity for a bad actor to compromise the release process of countless OSS projects.

Are you able to change those back for now? I'm comfortable with the use of the RedHat actions.

@stevespringett and @DarthHater FYI

[k3rnelpan1c-dev]

I too can not comprehend why GitHub decided to deprecate these two actions, hence why I searched and went with alternatives.
Regardless, I 100% understand and will revert to the GitHub ones :)