Consider whether configurable token prefixes should be nullable

We currently have two application settings that allow configuring token prefixes:

• personal_access_token_prefix
• instance_token_prefix

The latter is currently behind a feature flag but the personal access token configuration has been available for a while.

Based on recent issues (see #536734 (closed) and duplicate issues) it's clear we have a fair number of users that are choosing to set their personal access token prefixes to nil or empty. We currently allow this based on database constraints and model validations, but it's what caused the problem with the new feature that was rolled out.

Questions

1. What is leading these user's to want to remove the personal access token prefix?
2. What implications does this have for secrets detection and mitigating the effects of leaked tokens?
3. Should we require a prefix to be set (not nil/empty)?

It may be helpful context to note that there's a separate discussion in #388379 about the future of the personal access token prefix setting. In the future we may deprecate that in favor of the singular instance level prefix (the gl portion of glpat or glft (feed token), etc).