gitlab: accept routable personal access tokens - #1678

Fixes #1587

Summary

git bug bridge new rejects every personal access token that GitLab issues
today. The format check in promptToken only accepted the legacy token
shape:

re := regexp.MustCompile(`^(glpat-)?[a-zA-Z0-9\-\_]{20}$`)

That is an optional glpat- prefix followed by exactly 20 base62
characters. GitLab now issues routable tokens, which are much longer and
contain dots, so the regex never matches and the validator replies
token has incorrect format before the token is ever sent to the API.

The routable token format

Per GitLab's routable tokens design
document:

<prefix><base64-payload>.<token-version>.<base64-payload-length><crc32>

with a payload of 27 to 300 characters, a two character version, and the
length and crc32 each encoded in base36 on two and seven characters.

This matches tokens reported in the wild by
trufflehog#4551,
collected from both gitlab.com and a self-managed instance:

glpat-rQxN4XPLm8wF_jGbHv_A9731YZq2Kfe0BD.01.6z70tqjnm

and the token in the issue report:

glpat-bE8-c60h8AD4A0v-59rAr246MQj8ObF1DA.01.0y0nl1q64

Changes

• Keep the legacy expression for tokens that are still valid, and add a
  second one for routable tokens.
• Move both to package level as legacyTokenRe / routableTokenRe, behind a
  validTokenFormat helper, mirroring how bridge/github splits its
  legacyRe / re pair.
• Add TestValidTokenFormat, a table driven test in the style of the
  neighbouring TestProjectPath.

The API call in promptToken still decides whether a token actually works.
This check only exists to catch typos before a network round trip, so it
stays deliberately shape-only.

Note on the second symptom

The issue also reports Error: 87:11: illegal character U+002E '.' when the
regex is relaxed locally. That message is not produced by the bridge: the
illegal character %#U wording and the line:column position come from
go-git/gcfg, the git config parser behind
go-git's plumbing/format/config. I could not reproduce it against a
config written by git-bug -- I round-tripped a base-url of
https://gitlab.mycompany.com/ through repo.LocalConfig().StoreString and
reopened the repository cleanly. It looks like a separate parsing problem in
the reporter's environment, so I left it alone rather than guess at it.

Confidence Score: 5/5

_{Reviews (1) · Last reviewed commit: "gitlab: accept routable personal access ..." · Reviewed by Greptile}