Fixup nimbus-fml to download from archive.mozilla.org

[jhugman]

Fix EXP-3977

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due dilligence applied in selecting them.

Branch builds: add [firefox-android: branch-name] to the PR title.

[tarikeshaq]

to clarify the issue, and this is where it's a little tricky, the rust-component-swift version (number_string) we have here will always be 3 components. It's the AS_VERSION that may be two or three components. I can't think of an easy way to find out whether it's two or three components from here other than sending a network request and seeing if it's not a success

@bendk This makes me think we should think about policy a little, there are a few policy fixes for the future:

• If we make AS always be three or always be two components this will be simpler
• Maybe we could somehow decouple the version of the AS and the version of the FML?

[jhugman]

so this code maybe worth commenting.

The SPM has three components; this code checks that last component as the patch version (${number_string##*.}, then checks the length of the patch version component (${#patch}). If it's greater than 2, then treat it like a date stamp, and use it as a nightly. I figured that anything more than121.0.99 would be pathological as a release number.

[tarikeshaq]

Aaah I did misinterpret this so thanks for the clarification! Unfortunately, the issue is that the release version could be 121.1 or 121.0.1, but the scrip only sees 121.0.1 so we may want to strip the middle zero even on releases. You are correct however that nightlies should always be 121.TIMESTAMP

[jhugman]

Ok, going to talk in slack, then document here.

[jhugman]

Decided to not to look for a forever solution until mozilla-mobile/firefox-ios#17143 lands, then re-evaluate.

This PR should be good for then too.

[skhamis]

LGTM! Thanks for fixing this.