Change nightly call to support new API tokens

[j-rivero]

Build on top of #1201.

1. Adapt the release.py to not use the jenkins.ini file

The PR prepares the new auth method to work with nightly generation. To call release.py with osrfbuild bot account this PR implements the --auth parameter that supports user:token to be passes as argument to authenticate in our Jenkins. The token can potentially be a Jenkins API token or a GitHub Token. d7dcb2d

This has the side effect on the test code that we no longer need the _RELEASEPY_TEST_CREDENTIALS, removed in af2ecae.

2. Change release-tools DSL to modify the nightly_scheduler code

Remove existing shared token injection and use credentials plugin in Jenkins to pass GITHUB_TOKEN. Use that with the --auth mechanism implemented in 1. 85ea888

3. Test DSL to check that token is able to login in Jenkins and use the osrfbuild fork

Hijack part of #353 and add a test to check that that the token is able to login into Jenkins. 07a29cb. The new token should have the fine-grained permissions on osrfbuild/homebrew-simulation fork for "Contents".

⚠️ Existing problem

The existing GITHUB_TOKEN for the osrfbuild user in Jenkins does not seem to work to authenticate into Jenkins. This links with the old PR #353 that probably needs to be resurrected first.

Needs to merge solution to this in #1212 before

[j-rivero]

⚠️ Existing problem

The existing GITHUB_TOKEN for the osrfbuild user in Jenkins does not seem to work to authenticate into Jenkins. This links with the old PR #353 that probably needs to be resurrected first.

Investing this a bit more seems like Jenkins API tokens works nicely without making a crumb API call first https://issues.jenkins.io/browse/JENKINS-22474. To use the GitHub tokens we will need to implement the support for it in release.py and testing tooling. My proposal is to create an osrfbuild API token first and implement the support a new PR to avoid overloading this PR.

The other main question is: do we prefer to use an existing token from GitHub to authenticate into Jenkins with the osrfbuild or a Jenkins API Token. Pros and Cons:

• Jenkins API Token:
  • pros: better scoped for the goal.
  • cons: needs to create and maintain a new credential. Probably difficult to programmatically create and store it.
• GitHub Token:
  • pros: we can reuse the one used for osrfbuild GIT operations in Jenkins. Support in chef for it to be deployed in new buildfarms.
  • cons: support for requires crumb calls in scripting (as detailed before).

[j-rivero]

The other main question is: do we prefer to use an existing token from GitHub to authenticate into Jenkins with the osrfbuild or a Jenkins API Token.

After speaking with @nuclearsandwich, we agreed on using a manually generated Jenkins API Token. It is much better scoped for the task. I've added it and test in #1212

[j-rivero]

Cherry picking changes to #1201 manually. Closing this.