ci: [NGOv2.X] Automation of NGO releases

[michalChrobot]

Purpose of this PR

This PR automates the releases of NGO package (which can be extended for other packages since it's quite modular). The job will operate on the branch from which it will be triggered and by default it will be on the develop branch (job trigger).

For more background note that Netcode team sprint last 4 weeks, starting and ending on Wednesday and our goal is to kickstart the release process after last full week of the sprint and preferably release until next Wednesday (end of the sprint). So the goal would be to run everything on Saturday (after the week concluded) and have everything ready from Monday morning to Playtest/investigate failures.
As a separate part of this automation, as per THIS PR we are able to trigger builds of our samples so those will also be triggered on the weekend to be ready for playtesting on Monday.

Now with this in mind the process will work in the following way:

1. It runs on weekly schedule but we are interesting on executing it every 4th Saturday (after last full week of the Netcode team sprint. Our sprint last 4 weeks). Because of that the first action that this job will do is to run a check to see if the following requirements are satisfied:

• Is this the 4th Saturday since we last released?
• Is NGO CHANGELOG not empty? (no point of making the release is there is nothing to release)
• Is the release branch not yet created?

Before looking at the next steps, please note that as per THIS PR the package version of Nshould always correspond to the current state of the package.

2. If the above is satisfied the next step will be to create the release branch (based on the known package version). The already existing release.py script will be executed there in order to regenerate recipes, cleanup changelog and generally prepare our package for releasing (see result HERE)
3. The next step will be to trigger all_promotion_related_jobs_promotiontrigger job. In that way when we will set-up packageworks release stream on Monday morning we will already have the results from this job and we can address any potential failures.
4. As a last step the job will create a commit to the local branch (normally develop but for the sake of playtesting I used a test branch). The goal with changelog here is we want to avoid changelog divergence if release will take longer then expected. The script will clean the empty sections, assign correct release version and date and then add back the [Unreleased] section template for the purpose of next entries.
   The goal with package version is that we want to indicate that now the package reflects further state (next patch). After this the job will commit this to the branch.

I created Netcode-Team-Bot with appropriate tokens and marked committer to point to the bot (when for example making a direct commit to develop with changelog and package version update)

The bot will make commits like

Jira ticket

https://jira.unity3d.com/browse/MTT-12841

Documentation

After this gets merged I will add approperiate description of Netcode release process in https://docs.google.com/document/d/16g9B5jxXeV0zG44Fhax-6Md_gtLoqGVthKQ7LkDvdqM/edit?tab=t.0#heading=h.t1guku6agyev

Testing & QA

Since this automation runs on the same branch on which it's triggered (and just because of job trigger it will be develop-2.0.0 branch) I tested it locally (each script) and entire automation was tested on testing-automated-netcode-releases branch, the effects of which you can see as follows (note that instead of develop-2.0.0 I just used local branch):

1. I tested for the normal release schedule date (result HERE)
2. I tested with empty changelog (result HERE)
3. The job itself was green (LINK).
4. release/2.5.1 branch was created with proper initial setup (LINK), see latest commits there
5. Changelog and package versions were updated on develop-2.0.0 branch (replaced for testing with testing-automated-netcode-releases). Notice that this simulates what will happen on develop branch after this script runs. (LINK)
6. Wrench jobs were correctly triggered on the created release branch (LINK)
7. Builds were triggered from release branch (example build LINK)

Things to note

• Updating package version to next patch won't be immediately valid (vetting test will still compare it to latest released package version) but it serves the purpose of automating those steps and not needing to remember about it after package is released
• [email protected] was created to assign NETCODE_YAMATO_API_KEY to it. Additionally I created tokens for both GitHubs and when making commit I'm just pointing to this bot as committer and author.

Backports

It's backported to #3603

[EmandM]

I had the tiiiniest nit-pick. Definitely not a blocker. This looks great!