bug fix: mobynit: harden GOPROXY fallback during compile

[billmcilhargey]

Summary

• add https://goproxy.io to the default GOPROXY chain before the existing direct fallback
• retry oe_runmake once during do_compile to absorb transient TLS stalls while fetching Go modules
• document the intent in the recipe so the network-hardening behavior is clear

Issue

Closes #3850

Why

mobynit can fail during do_compile when Go module downloads hit a transient TLS handshake timeout against proxy.golang.org.

Before this change, the recipe used a single public proxy plus direct, which left builds exposed to intermittent failures from that one upstream. This change makes module resolution more resilient by adding a second public Go proxy mirror and retrying the compile once when the failure is transient.

Testing

• verified the branch diff against origin/master
• confirmed the recipe now sets:
  GOPROXY ??= "https://proxy.golang.org,https://goproxy.io,direct"
• confirmed do_compile() now exports GOPROXY and runs:
  oe_runmake || oe_runmake

Manual test case

1. Build an image that includes mobynit on the affected branch baseline.
2. Observe intermittent do_compile failures when module fetches time out against proxy.golang.org.
3. Build the same target with this patch applied.
4. Confirm the build can fall back to goproxy.io or retry successfully instead of failing immediately on a transient TLS stall.

---

Contributor checklist

• Changes have been tested
  • Covered in automated test suite
  • Manual test case recorded
• Change-type present on at least one commit
• Signed-off-by is present
• The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

[github-actions]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[github-actions]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[flowzone-app]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.