Support using `GITLAB_PAT` for authentication

[toph-allen]

Intent

Fix source downloads from private GitLab repositories by preferentially using GITLAB_PAT for authentication.

Fixes #673

Approach

The GitLab downloader now checks for a GITLAB_PAT. If that exists, instead of creating the username/password auth, it adds Private-Token to the request's headers.

GITLAB_USERNAME and GITLAB_PASSWORD were removed. See this comment for why.

Automated Tests

There were no automated tests for GitLab download functionality before. There is one test that is skipped unless run manually.

This PR adds no tests.

QA Notes

I validated this against a private repo on my GitLab account. Validation is tricky, requiring a Packrat lock file that restores from a GitLab repository.

To validate:

1. Download and extract this archive: packrat-with-private-package.zip
2. Get access from me to the private package hosted on GitLab that this package attempts to restore.
3. Create a GitLab PAT and make it available in your terminal's environment as GITLAB_PAT.
4. Install this branch's version of Packrat.
5. Start an R session in the archive's directory that contains a packrat subdirectory. Run packrat::restore(). The environment should restore correctly.

We should also confirm:

• If the GITLAB_PAT environment variable is missing, an error message is displayed.
• If GITLAB_USERNAME and GITLAB_PASSWORD variables are present and GITLAB_PAT is absent, the same error message about GITLAB_PAT is displayed.

Checklist

• [x] Added NEWS entry

[toph-allen]

I haven’t found any historical reference to GitLab ever allowing basic password auth in its API, even going back into old issues and StackOverflow posts. I wondered if I was missing some search term. The original implementation was tested against a public repo and followed the Bitbucket implementation (Bitbucket does use username and password).

I think it's likely that GitLab has never supported basic auth with username and password, and that this feature has just never been exercised properly due to renv's availability and Connect not supporting restoring packages from private sources.

@aronatkins , do you think it makes sense to remove the GITLAB_USERNAME and GITLAB_PASSWORD “capability” entirely from packrat? I think that leaving it may only serve to send users on a wild goose chase.

[toph-allen]

@aronatkins I removed GITLAB_USERNAME and GITLAB_PASSWORD support in the latest commit.

• After an exhaustive search of the web (StackOverflow, GitLab's own issue tracker and community forum, relevant issues on Packrat and Connect repos, and the RStudio community forum), I found no evidence that GitLab ever supported authenticating calls to its API with username and password, or that anyone had tried to use Packrat in this way. Even five years ago, token-based auth was all I found.
• This was added three years ago, and the work seems to only have been verified with public packages. At that point, renv already existed and supported GitLab.
• Because this was mainly only used in Connect, and there were other known barriers to restoring private packages on Connect, this was never discovered.

Removing it from Packrat will avoid sending users down a dead end.

[toph-allen]

CI is failing on oldrel-1 — it looks like network errors in apt-get or something like that.