delay downstream releases until pre-release promoted to latest

[qrkourier]

We're releasing the Linux packages and container images when the GitHub release is published, but not filtering for pre-releases vs. "latest" releases, which is a feature of GH Releases API.

Delay releasing those downstream artifacts, which can not be clawed back, until the GitHub release is flagged "latest."

This adopts a similar pattern as used by ZET to ensure a greater burn-in for the downstreams, and sets a more conservative expectation for GitHub pre-releases.

[qrkourier]

This will involve a combination of event-specific and activity-specific workflow triggers like this:

  release:
    types:
      - released  # excludes "prereleased" which is included in "published" to
                  # avoid prematurely releasing semver tagged container images

and new conditional expressions within the main.yml workflow that's currently calling the workflows where the images and packages are built and published.

The pattern I used for ZET was to publish releases to a test repo, then later promote the artifact to the main repo when the GitHub release is promoted to latest.

[qrkourier]

There's an issue with the way we're computing Linux package prerelease versions.

We're adding a prerelease version string as a tilde-separated suffix to the prior release, which in semver evaluates as a lower version than the prior release, not a subsequent version.

If the prior release was 1.1.1, and we are building a branch based on that version, then we should increment the patch version and add a prerelease suffix like 1.1.2~8851136463. Currently we're expressing this as 1.1.1~8851136463, which package managers obediently evaluate incorrectly as an older version.

[qrkourier]

Use ziti-ci get-next-version instead of get-current-version when building the pre-release semver!