[jaeger-v2] Release process

[yurishkuro]

We plan to continue supporting v1 components even after we release Jaeger v2, at least for a year. During that period we need to enhance our release process such that both v1 and v2 artifacts are published, as well as make the corresponding changes to the documentation.

Proposed release process:

• We will continue releasing v1 and v2 components from a single main branch of jaeger repository
• Each release will have two tags, a continuation of the existing 1.x version tags, and a new series of 2.x versions.
• The 2.x versions will initially have the form 2.0.0-rcN and we will keep incrementing N.
• There will be just a single combined release on GitHub, with both versions in the title, e.g. 2.0.0-rc1/1.61.0
• The binary artifacts for v2 will be uploaded as a separate set of archives, each will include only the jaeger binary
  • That means the schema / rollover scripts are still going to be 1.x - we could reconsider that and bundle them into 2.x too
  • Going forward we want to get rid of schema / rollover scripts and incorporate them directly into the binary (e.g. Create database scheme in Cassandra automatically #5797)

Tasks:

• change build info determination to allow for dual versions
• implement ability to do a dry run of the release workflow
  • skip binary signing in scripts/package-deploy.sh or define temporary key
• decide: should scripts receive versions as arguments or lookup the git tags directly?
• consider changing release workflow to manual trigger. It can ask for two versions, validate their syntax and that they do not exist (if they do exist, it would require an additional override flag)
• enable versioned release of jaeger v2 binary (we only release latest now)
  • compute-tags.sh does not understand semver-rcN syntax
• package jaeger v2 binary as a separate release artifact (currently not included in scripts/package-deploy.sh)
• revisit the use of BRANCH variable
• revising build-binaries-*** Makefile targets, they sometimes include os-arch, sometimes just os, simetimes just arch - it's a mess -- Normalize build-binaries targets #5924
• figure out how publish release workflow will work with dual versions. Should it still run on release/published event or rather on tags?
  • New process documented in RELEASE.md. Because we need two tags in the repo, they have to be applied manually, not via GH Release, which can only create one tag.
  • The GH Release can still trigger the release workflow, right now it has to be triggered manually after the release is published (because it will try to upload artifacts to a release).
• figure out how release notes script will work with dual versions
• do we need dual version for the UI? -- continue using 1.x for now, once 2.x officially released switch UI version to 2.x, but still use a single version
• documentation versioning mechanism