[Tooling] Add initial release lane setup

[iangmaia]

Fixes AINFRA-947

Description

This PR contains the initial work for building and uploading releases to the Google Play Store on CI.

I've started adding the basics of version management utilities and the upload to a GCP testing track so we can validate the entire flow and the security setup, with a lane that can be run locally and trigger the release process in CI.

In the next iterations, we can further automate release uploading to other tracks (including production), updated metadata such as the app changelog, create GitHub releases, etc, while we also mature the release lifecycle according to the project's needs.

Testing Steps

1. Make sure you have rbenv setup and environment variables such as GITHUB_TOKEN and BUILDKITE_TOKEN.
2. Checkout this branch
3. Run bundle install
4. Run bundle exec fastlane new_alpha_release. This will print what the lane will do and ask for confirmation.
5. After the confirmation, the lane should commit a version bump and trigger a build on CI. It should print the URL of the build so you can follow it.
6. The version should have been uploaded to Google Play Console. It should be under Test And Release - Testing - Internal Testing as a new draft (it seems it's not possible to upload non-drafts to a draft app).

[iangmaia]

This pipeline is to start the alpha release process completely from CI (eventually from ReleasesV2).

[hamorillo]

I can't say much about the pipeline code 😅 . I've tested it and works as expected. I can see the release on Google Play Console:

[iangmaia]

@AliSoftware I've updated release-toolkit to 13.4.0 and the versioning scheme in the project.
I'll run tomorrow a new_alpha_release -- we'll need to first bump the versionName to 0.21, given it now the minor component has 3 digits, but from what I see everything seems fine in the new DerivedBuildCodeFormatter. Then we can finally merge this PR and have this versioning moving forward.

[AliSoftware]

[AliSoftware]

💡 🔜 Note for the future (definitively not for this PR, just ideas for improvement later):

1️⃣ We have *BuildCodeCalculator classes in release-toolkit (e.g. SimpleBuildCodeCalculator, DateBuildCodeCalculator) to compute the next build code for those.
So we should probably consider creating a similar DerivedBuildCodeCalculator in release-toolkit, with def next_build_code(version:) method that would do what you did here, for us to abstract that logic away from the Fastfile.

2️⃣ It has also been in my mind for a very long time to also make a VersionManager class that would expose all those build_code_current, build_code_next, release_version_current, release_version_next methods that we keep redeclaring in the Fastfile of all of our repos, and that would encapsulate the assembly of the version calculator + formatter and build code calculator + formatter, so that we can still assemble each individual component like pieces of lego, but in the end have a single object to manipulate. For example:

VERSION_MANAGER = Fastlane::Wpmreleasetoolkit::Versioning::VersionManager.new(
  version_calculator:  Fastlane::Wpmreleasetoolkit::Versioning::SemanticVersionCalculator.new,
  version_formatter: Fastlane::Wpmreleasetoolkit::Versioning::RCNotationVersionFormatter.new,
  build_code_calculator:  Fastlane::Wpmreleasetoolkit::Versioning::DerivedBuildCodeCalculator.new,
  build_code_formatter: Fastlane::Wpmreleasetoolkit::Versioning::DerivedBuildCodeFormatter.new(prefix: '1', major_digits: 2, minor_digits: 3, patch_digits: 1, build_digits: 2)
)

And then we could do every version-related actions in the rest of the Fastfile using the VERSION_MANAGER as the single API interface to interact with, which would take care to delegate to the calculators/formatters as needed.
For example, just calling VERSION_MANAGER.build_code_next would take care of using its @version_formatter to parse the version file, use its @build_code_calculator to increment the value, and its @build_code_formatter to return the incremented build code—mostly like you do here in your own def build_code_next method, except that we wouldn't need to declare such a method in each of our Fastfile files anymore as the implementation would have been DRY'ed into the VersionManager class from release-tookit.

To get there we might need to first make sure all the *BuildCode* classes inherit from the same abstract class and have a common API, so that the VersionManager class can call the same methods on those regardless of which subclass is actually used. But I think the end result would be really great with a lot of simplification in our Fastfiles and all more consistent APIs and setups across repos.

Of course, this would be its own project, for a later time, and completely unrelated to this PR. But I figured I'd share the idea while at it, to keep in the back of our minds.

[iangmaia]

make a VersionManager class that would expose all those build_code_current, build_code_next, release_version_current, release_version_next methods that we keep redeclaring in the Fastfile of all of our repos

As @ParaskP7 says, 💯 ^ 💯 ^ 💯 ! 😄

Something like that also crossed my mind multiple times. This is pretty much a constant across many repos and it would be great to also standardize on naming (some repos have these common functions slightly different).

[ParaskP7]

As @ParaskP7 says, 💯 ^ 💯 ^ 💯 ! 😄

Ah, I am just using 💯 x 💯 ^ 💯 , using x then ^ 😄 but you took it to the next level, using ^ followed by another ^ 🐡 my brain just can't cope with this yet! 🤣 🤣 🤣