Add rapids-retry to gh commands

[jayavenkatesh19]

This PR addresses nightly CI test fails due to wrong Github actions run ID being picked up, and also add the rapids-retry function to any gh cli calls to avoid failures due to network inconsistencies.

[ajschmidt8]

approving and merging but I've asked @VenkateshJaya to document the use of the new RAPIDS_BUILD_WORKFLOW_NAME variable in the body of this PR for posterity.

[jayavenkatesh19]

Due to the switch in storing build artifacts on Github Artifact Store rather than S3 (downloads.rapids.ai), there is a change involved in the way artifacts in nightly builds are handled.

Previously on S3, when the build.yaml workflow is triggered by the nightly trigger, all the build artifacts were uploaded to a S3 path like /repo/nightly/sha and the test.yaml workflow run was able to download these artifacts as they have the same commit and use them for build tests.

However, on Github, artifacts are contained within a workflow run and due to the fact that build and test are runs of two different workflows, this is causing the test workflow runs to fail due to artifacts not being present within the run.

To handle this, when downloading artifacts on nightly workflows, we will be querying all the runs associated with that specific commit, and using artifacts from the build.yaml workflow of that specific commit.

There is a possibility for edge cases to exist in this scenario, like when the artifacts to be tested are built on a different workflow other than build.yaml. For such scenarios, the RAPIDS_BUILD_WORKFLOW_NAME env-var is introduced which can be used to specify the name of the workflow file (only works if a run is made on the specified commit) from which artifacts are to be downloaded.

I will be opening a PR on shared-workflows to add this optional input for these edge cases and linking it here.

See rapidsai/shared-actions#52 and rapidsai/shared-workflows#331