Get version code from API and use semantic versioning

[LuisDuarte1]

Closes #985
Closes #1108

This makes the versioning more versatile by:

• Getting the version_code from the Google API to avoid conflicts
• Uses semantic versioning to distinguish beta and production tracks better
• Supports Fixes on the production/master branch

[codecov]

Codecov Report

Merging #1109 (3d1c25f) into develop (96c2822) will increase coverage by 1%.
Report is 1 commits behind head on develop.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##           develop   #1109   +/-   ##
=======================================
+ Coverage       16%     16%   +1%     
=======================================
  Files          220     220           
  Lines         6648    6648           
=======================================
+ Hits          1047    1050    +3     
+ Misses        5601    5598    -3     

[limwa]

I've been going through the PR and I have two questions:

1. What happens in the case that our app update is blocked by a review from Google (since the version comes from the Google Play API)?
2. What does this new action do differently that allows it to fulfill its objectives? I've seen things about reading the hash of the commit in the original branch instead of the merge commit and I couldn't understand why we are doing that. If you could please explain, that would help a lot.

[LuisDuarte1]

What happens in the case that our app update is blocked by a review from Google
(since the version comes from the Google Play API)?

I think that the edge case is handled by my action because it uses the API call edits.bundles.list which includes all uploaded bundles, even rejected ones, which resolves the duplication of the version code (which is the most important, because it must be unique). I'm not too sure about the duplication of the version name, but it's generally accepted on the marketplaces (and this edge case will not happen frequently, so the eventual duplication of one version name is acceptable imo).

What does this new action do differently that allows it to fulfill its objectives? I've seen things about reading the hash of
the commit in the original branch instead of the merge commit and I couldn't understand why we are doing that. If you could
please explain, that would help a lot.

The old action stored the version exclusively in the repository, using a git push --force (which already resulted in some complications in the past, yikes) to sync the version codes between develop and master branches. The new action uses the Google API and makes the syncing of version codes (and eventually version names) not rely on files in the repository (and weird methods to sync them between branches). The new action also makes the version names more semantic (using prerelease versions on develop, and minor and patch types on master).

We make some assumptions about the master branch, to simplify the action itself: we assume that the master branch will always be protected, in a way, that requires a PR that is merged using a merge commit. We use the original branch hash, to evaluate if the commit came from develop or not (this was somewhat done in the previous action too). This is used mainly for versioning, a commit that comes from develop bumps the minor version, but if it doesn't come from develop (which means it's a fix) it bumps the patch version.

There are also other ways to do this, such as relying on pull_request events instead of push events, or even, making a PR into master require a label that is a bump type (patch, minor, major), but I think that the logic here is more straightforward than relying on pull_request events.