feat(CI) - add possibility to point harmony-test repo to non-master branch via CI and locally

[mur-me]

TL;DR: this PR give us an easier way to point to any harmony-test repo branch, details below.

What was done:

• add possibility to point harmony-test repo to non-master branch via CI, for this I've added this logic -

  harmony/scripts/travis_rosetta_checker.sh

  Lines 5 to 8 in 8b1cda4

  	# handle for the Travis build run:
  	# * uses TRAVIS_PULL_REQUEST_BRANCH for RP branch
  	# * uses TRAVIS_BRANCH for simple branch builds
  	MAIN_REPO_BRANCH=${TRAVIS_PULL_REQUEST_BRANCH:-${TRAVIS_BRANCH}}

  , if it is PR - use special PR env, if it is regular branch - use branch env.
  • Q: why not to check it vice-versa like MAIN_REPO_BRANCH=${TRAVIS_BRANCH:-${TRAVIS_PULL_REQUEST_BRANCH}}?
  • A: Because TRAVIS_BRANCH becomes the branch name in which you want to merge, dev in my case
• add MAIN_REPO_BRANCH to point exactly the same repo version in the test run instead of hardcoded main branch
• cover local runs of travis_rosetta_checker.sh and travis_rpc_checker.sh, it will support the same logic as in CI, if your branch in already on remote, else use dev branch for harmony-test repo

===

• Example run in the CI - https://github.com/harmony-one/harmony/pull/4730/checks?check_run_id=28572079834
• example local run for the travis_rpc_checker.sh, you can see the main branch name used by harmony-test repo in the last log line:

user@laptop:~/go/src/github.com/harmony-one/harmony$ ./scripts/travis_rpc_checker.sh 
[harmony-test repo] - working on 'master' branch
[harmony repo] - working on 'feat/TRAVIS_CI_add_possibility_to_point_to_non_master_branch' branch
...
=> [ 8/23] RUN git clone --branch feat/TRAVIS_CI_add_possibility_to_point_to_non_master_branch https://github.com/harmony-one/harmony.git > /dev/null 2>1

• the same logic applies for the local rossetta tests:

user@laptop:~/go/src/github.com/harmony-one/harmony$ ./scripts/travis_rosetta_checker.sh 
[harmony-test repo] - working on 'master' branch
[harmony repo] - working on 'feat/TRAVIS_CI_add_possibility_to_point_to_non_master_branch' branch
...
 => [ 8/23] RUN git clone --branch feat/TRAVIS_CI_add_possibility_to_point_to_non_master_branch https://github.com/harmony-one/harmony.git > /dev/null 2>1

• example of fresh local-only branch run, you can see this WARN about local only:

user@laptop:~/go/src/github.com/harmony-one/harmony$ ./scripts/travis_rosetta_checker.sh 
[WARN] - Git branch 'test_demo' does not exist in the remote repository, using 'dev' branch as a workaround for a local-only branch
[harmony-test repo] - working on 'master' branch
[harmony repo] - working on 'dev' branch
=> [ 8/23] RUN git clone --branch dev https://github.com/harmony-one/harmony.git > /dev/null 2>1

Issue

Test

Unit Test Coverage

Before:

<!-- copy/paste 'go test -cover' result in the directory you made change -->

After:

<!-- copy/paste 'go test -cover' result in the directory you made change -->

Test/Run Logs

Operational Checklist

1. Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)

   YES|NO

2. Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.

3. Describe how the plan was tested.

4. How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?

5. What are the planned flag epoch numbers and their ETAs on Pangaea?

6. What are the planned flag epoch numbers and their ETAs on mainnet?

   Note that this must be enough to cover baking period on Pangaea.

7. What should node operators know about this planned change?

8. Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)

   YES|NO

9. Does the existing node.sh continue to work with this change?

10. What should node operators know about this change?

11. Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?

TODO

[GheisMohammadi]

Great job 👏