Refactor daily status health check to handle triggered builds and verify published assets

[andrew-m-leonard]

Fixes #787
Fixes #798

Update the daily Slack build pipeline health status:

• Handle build tag triggered builds that do not have a max stale days.
• For build tag triggered builds, confirm the latest published binary is the latest upstream openjdk build tag.
• For all versions, verify the latest published (according to API) binaries have all the required artifacts.
• Simplify the build&test success rating to simply find the last pipeline build from the trss API
• Parameterise the featureReleases and optional "tipRelease" versions

Added job Parameters:
FEATURE_RELEASES: List of jdkNNu releases to get status of
TIP_RELEASE: Optional jdk(head) release version (eg.jdk22)
BINARIES_REPO: github.com binaries repo template (eg.adoptium/temurin_NN_-binaries)
BUILD_CONFIG_URL: URL of raw ci-jenkins-piplines pipeline configuration for obtaining required Arch's for version

Test Slack status example: https://adoptium.slack.com/archives/C598A7EMQ/p1693580500301949

Missing Windows SBOM artifacts discovered with this work, raised as issue: adoptium/temurin-build#3464

[jerboaa]

Personally I find the added condition to mark the build status as unhealthy when a build artefact is missing a bit noisy. I'd be primarily interested in a basic "is there a new EA binary to test available" message, which is now hard to discern on this extended status. Perhaps that's a non-issue, and this new status will mostly work fine, but if it turns out to be red 99% of the time, it starts to become less informative and becomes noise.

Perhaps we want two status answering the following to basic questions?

1. Is a binary available for testing (used to be Linux x86_64)?
2. Are there any missing artefacts? If so, which.

Thoughts?

[andrew-m-leonard]

Personally I find the added condition to mark the build status as unhealthy when a build artefact is missing a bit noisy. I'd be primarily interested in a basic "is there a new EA binary to test available" message, which is now hard to discern on this extended status. Perhaps that's a non-issue, and this new status will mostly work fine, but if it turns out to be red 99% of the time, it starts to become less informative and becomes noise.

Perhaps we want two status answering the following to basic questions?

1. Is **a** binary available for testing (used to be Linux x86_64)?

2. Are there any missing artefacts? If so, which.

Thoughts?

@jerboaa Thanks for the Feedback.
So this change is partly driven by are gradual change to only doing EA builds when the upstream tag gets published, and the importance of making people/us aware if there is something wrong/missing, with the latest available EA tag build, as no repeat build will occur.
The intention is this daily status should ALWAYS be "Healthy", and if not we act upon it quickly to make it so... Being Healthy, means ALL platforms are available at that latest build tag.
Previously, the "health" was just based on a publish x64Linux being available and published within last 5days, it gave no information on whether other platforms were also available.
So, the intention should be:

1. A "Healthy" indication that a binary for your chosen platform is available, and the name and link of that EA build
2. In the case of "Unhealthy" a list of the artifacts/platforms that are missing from that build. Which we will then act upon to resolve...

[jerboaa]

The intention is this daily status should ALWAYS be "Healthy"

Alright. If the intention is to keep this healthy, I have no concerns with this. We'll see how it goes.