Download node binary in GH action

[yhwang]

Description

Add a script to download node/yarn binary in GH action with retry feature to prevent the unstable connection when downloading the node/yarn binary in the Maven build.

fixed: #22676

Motivation and Context

Use the retry mechanism to avoid the unstable connection when building the presto-main

Impact

In the GH action workflows, run the script with the maven cache population.

Test Plan

Verify the CI runs for this PR

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

Please follow release notes guidelines and fill in the release notes below.

== NO RELEASE NOTE ==

[yhwang]

this CI run: https://github.com/prestodb/presto/actions/runs/8980256103/job/24663568049?pr=22683 hit the cache.
let me comment out part of the script to run the node/yarn binary download logic. I will uncomment the code after verification.

[yhwang]

this CI job: https://github.com/prestodb/presto/actions/runs/8980341932/job/24663806501?pr=22683 verified the download_nodejs code. No maven cache and download_nodejs did retrieve node/yarn and store them into the maven cache. in the Maven Check job, the frontend plugin uses the binary files from the maven cache to install node/yarn.

ready to uncomment the code and revert the pom.xml change.

[elharo]

Is there any possibility we could load everything including node from the Maven repository system instead? This separate load mechanism has proved to be a large problem for those of us behind corporate firewalls.

[yhwang]

@elharo unfortunately, node/yarn is not in the Maven repo. and I agree with you about the corporate firewall. The same issue also applied to Docker Hub or other services with rate limits based on IP address. As for node and yarn, they shouldn't be blocked by the corporate firewall since most of the developers need them. I believe corporates should have proxy/caching for those tools.

The solution here is for GH action and that's why the script is put under the .github/bin directory. Based on the current workflows, if the Populate maven cache job fails, the workflow will fail. Downloading the node/yarn and putting them into the Maven local cache with retry should avoid the unstable connection issue. Once the Populate maven cache succeeds, the cache could be reused by other workflows.