WIP: start with pipeline for official release (without manual steps)

[andife]

Description

Remove manual steps for the official release build.

Motivation and Context

#5927

Open points? Points to discuss?

I see a few different options we have maybe. Maybe the "most critical" point is publishing to pypi, as we cannot undo that.

Option A): Create a tag from the github webinterface

1. for a specific release branch => set a tag
2. our pipeline(s) will run
3. github release is created by the pipeline
4. different files produced by the pipline are uploaded to the github release section, and wheels are published to pypi automatically
5. We have change the release notes afterwards?
6. Advantages: 1. Regarding automation / supply chain security like sigstore / slsa you could then automatically upload the corresponding files to github release
7. Disadvantages:
   1. We have change release notes afterwards?
   2. Maybe not really clear why we should only tag if we want to have a relase

Option B ): Create a release from the github webinterface.

1. https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release => Maybe the way to go, because when we want to create a release, why should we do that by creating a tag before?
2. Click to release button at the github webinterface (who has the rights to do that? do we have a group, who is managing that?)
3. There we would have the option to i Choose an existing tag, ii) choose an release branch to create a tag based on that.
4. Probably we would choose ii) Then our pipelines would run... as we have already created the release by the github gui functionallity, we would only need the gh upload step to upload for example sigstore and slsa stuff (for the different release pipelines)
5. Disadvantages or currently still unclear to me: We have different pipelines, which can add different data to the github release. Let's say linux ran first, then the win and mac pipeline can still add hashes or keys for sigstore / slsa. (I assume it should work)

Option C): Split Tag creation and release

1. Advantage: We have more control what we publish? As we could see the run artifacts before?
2. Disadvantage: We cannot cannot reuse the created artifacts from the build run? Yes they are somehow connected to the pipeline, but in order to keep them longer, they have to be added to the for example github release section?)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 56.81%. Comparing base (6eb45c0) to head (90230ac).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5939   +/-   ##
=======================================
  Coverage   56.81%   56.81%           
=======================================
  Files         506      506           
  Lines       30370    30370           
  Branches     4592     4592           
=======================================
  Hits        17256    17256           
  Misses      12285    12285           
  Partials      829      829           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[liqunfu]

It is beneficial of publish to pypi without need of access to pypi.

[justinchuby]

We also need the commit to be in an rel-* branch I think?

[justinchuby]

I think we can assume a release has been created when this pipeline is triggered, because we use the release feature to create the tag.