feat(metrics): Add scopes to Glean access token check event

[vbudhram]

Because

• We want to see the scopes in our Glean events for access token checked

This pull request

• Adds the scopes as a sorted, comma separated string to those events

Issue that this pull request solves

Closes: https://mozilla-hub.atlassian.net/browse/FXA-10484

Checklist

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).

Other information (Optional)

@chenba You are probably the best to review this. I wasn't sure if this was the correct way to add an extra value to Glean events. I didn't want to piggy back off the reason value since it didn't seem to make sense in this case.

[vbudhram]

Does Glean support Array types? Would that allow for easier sorting and graphs?

[chenba]

Unfortunately, the String List type is not support for the extra keys. 😞

[chenba]

@bbangert @vbudhram what do you think of filtering out the common scopes (e.g. 'profile')?

[chenba]

Thanks, @vbudhram. LGTM but let's see what Ben think of filtering out the common scopes. I think the intention is to use the scopes to understand what product/client is making the request; the common scopes don't really help with that.

[bbangert]

LGTM!

[bbangert]

The common scopes don't help, but I don't think they'll hinder either. However they could result in an increase in cardinality, so filtering out the profile/identity/openid basic ones should be done.

[bbangert]

I don't think filtering out the common scopes will matter here, mainly since I believe we'll be doing more specific queries in Looker/etc to quantify the other resource requests. The list of FxA handled scopes can vary greatly over time as well, so keeping those up to date and mapped to 'external' resource servers or not will probably be more time intensive than just adding a Looker view to see access token issuance for all tokens with scope including 'relay', etc.

This list may grow in cardinality over time if clients start doing more specific requests, e.g. read to 2 scopes, write to 3, etc. But should still be a fairly confined list.

Do we have a white-list of all valid scope strings we verify this input on? e.g. this scope set data isn't completely unfiltered client-sent data?

[vbudhram]

Do we have a white-list of all valid scope strings we verify this input on? e.g. this scope set data isn't completely unfiltered client-sent data?

Looks like we do store a list in the database and request checks that the scope is valid, so in theory should only see valid scopes in Looker.