CustomersDot <> GitLab.com Access Token Short Expiry

## Summary

Unsure if this is a "bug" per se, and [from slack discussions](https://gitlab.slack.com/archives/CMJ8JR0RH/p1653039025967549), nothing on cdot code has changed recently.  But multiple support engineers have noticed this as seemingly different from how it worked until now.

Recently (within the last week as of 2022-05-23), Support team has noticed customer's cDot accounts no longer being linked to their GitLab.com users.  From admin point of view, "GitLab Groups" page shows `Customer has not linked their GitLab.com account.` even when the Customer record has a `uid` and `gitlab` provider.  This creates an extra challenge for us on the support side due to reduced visibility on customer's namespaces.

From a customer POV, My Account > Your GitLab.com account shows `No account linked.` _unless_ the view is loaded as a customer logging into cDot using their GitLab account.

In the history tab, very recent entries exist nullifying the access token.  For example, [my account on customers.staging](https://customers.staging.gitlab.com/admin/customer/59644): 

> 2022-05-23 13:35 | khughes+test63@gitlab.com | update [updated_at = 2022-05-23 13:35:35 UTC, access_token = ] 

The Provider is (and has been) `gitlab` and UID is `1688436` ([my staging account](https://staging.gitlab.com/khughes))

The question here is: what changed and is it worth investigating?

It seems like nothing on cDot side has changed recently, so perhaps GitLab.com side?

### Support impact

There are a few services on cDot side which do rely on user-level access token when available, for example [Gitlab::HostedPlans::CreateTrialService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/b3f20f2538d4da3bd016e19f86938e118f420f76/app/services/gitlab/hosted_plans/create_trial_service.rb#L115-121).  Support tooling [relies on that service](https://gitlab.com/gitlab-com/support/toolbox/console-training-wheels/-/blob/master/lib/support_team.rb#L143) for "extending" expired subscriptions; it doesn't currently supply an admin token so it fails to work otherwise.  Anecdotally speaking, this has worked fine up until very recently where we're now seeing accounts that had persisted access_tokens being invalidated.

### Customer impact

For the customer purchasing perspective, it contributes to a bit of a confusing process when managing an existing subscription.  Again, using my staging account (which was previously linked), trying to add minutes into an existing sub:

![screenshot-2022-05-23-10_29](/uploads/0961cc676bc8241044eaea608396cb72/screenshot-2022-05-23-10_29.png)

Sends me to the purchase URL (`https://customers.staging.gitlab.com/subscriptions/new?plan_id=2c92a0086a07f4a8016a2c0a1f7b4b4c&subscription_id=A-S00082613&transaction=ci_minutes`) now requiring an extra step to re-link: `https://customers.staging.gitlab.com/auth/gitlab?redirect_to=https%3A%2F%2Fcustomers.staging.gitlab.com%2Fsubscriptions%2Fnew%3Fplan_id%3D2c92a0086a07f4a8016a2c0a1f7b4b4c%26subscription_id%3DA-S00082613%26transaction%3Dci_minutes`

which resulted in a 404

![screenshot-2022-05-23-10_30](/uploads/2146394e4d2f48c58dfdaf04f790774c/screenshot-2022-05-23-10_30.png)

Refreshed the page landed me back at the purchase workflow

![screenshot-2022-05-23-10_31](/uploads/7c66b37a566044ccc83d97a40ed32e59/screenshot-2022-05-23-10_31.png)

## Workarounds

* Have the customer re-link their account, possibly every few hours?
* Note for console users needing to workaround it: pass `is_admin=true` to [BaseTrialService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/cc75943924e1874a37640dca3929d2ca023d29c5/app/services/gitlab/base_trial_service.rb#L11)

Example:  https://gitlab.zendesk.com/agent/tickets/303004
<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 3.0