[Tooling] Improve new_hotfix_release lane to work when there's no release tag

[iangmaia]

Related to AINFRA-1518

Description

This PR aims to add more robustness and require less manual intervention to the hotfix creation lane new_hotfix_release.

We have observed that sometimes it is possible that the release has been finalized but a release tag isn't present yet for some reason (likely due to the fact that the release hasn't been published yet), so release managers will get an error and require manual intervention.

This PR changes the code so that, if no release tag is present, we start the hotfix branch based on the corresponding release branch.

Testing instructions

These are some test scenarios that can be simulated:

1. There is a release tag that can be used to create the hotfix branch
2. There's no tag, but there's still a release branch that can be used to create the hotfix branch
3. There's no tag or branch (error)
4. The provided version doesn't have a patch component like 30.6 instead of 30.6.1 (error)

To test it, you can create test branches / tags (⚠️ delete them later or, even better, use this technique of pointing your working copy’s origin remote to a local bare repo instead ⚠️ ) and run bundle exec fastlane new_hotfix_release skip_confirm:false version:"$VERSION" and then answer no after the prompt so that the lane execution stops and check the printed values.

For example:

1. Create and push release branch release/30.6 (which doesn't exist and has no corresponding tag for that version)
2. Run bundle exec fastlane new_hotfix_release skip_confirm:false version:30.6.1
3. It should use the release/30.6 branch instead of trying to use a tag. It should print:

ℹ️  Tag '30.6' not found on the remote. Using release branch 'release/30.6' as the base for hotfix instead.

New hotfix version: 30.6.1
New build code: 30.6.1.0
Branching from release/30.6

Do you want to continue? (y/n)

[AliSoftware]

💡 Add a sh('git', 'fetch', 'origin', base_ref_for_hotfix) call before the create_branch call to make sure that the remote base we're creating the branch from is fetched in the local working copy beforehand.

Otherwise there's a risk that the release/x.y previous branch exists on the remote but hasn't been fetched into the local working copy yet, which will make the create_branch fail. Not sure that will ever happen, but better safe than sorry?

(See my similar comment on other similar PRs in other repos)

[iangmaia]

Just to mention it here, I've implemented fetching base_ref before creating the branch in all repos (here in 701debb).

[mokagio]

Tested a few scenarios locally. I didn't take screenshots because of the many logs lines.

I also compared this code with that of other PRs that @AliSoftware previously approved.

---

The Prototype Build failure in the checks is obviously unrelated and we can ignore it. FWIW, it's a time out on the cleanup stage.

[iangmaia]

@AliSoftware I've implemented the last change we discussed about ensuring the hotfix branch doesn't exist on 458e13d .

[AliSoftware]

Tested all 4 scenarios (invalid hotfix version number, neither tag nor release branch, no tag but a release branch, tag present) and all worked as expected.

Left a small nit but approving to unblock.

[AliSoftware]

Nit: wouldn't it make more sense to test this sooner in the lane (e.g. line 422)?