Evaluate using Gitlab as a composer registry for extensions

Previous discussions:

• https://github.com/adixon/ca.civicrm.logviewer/pull/25
• https://github.com/totten/civix/pull/267

Recap:

• Tim had worked on Comex a while back, a standalone PHP app: https://lab.civicrm.org/infra/comex
• There are mixed feelings about how to handle dependencies, and we would definitely not want to require composer for everyone, but many of us do use it to manage codebases.
• @sluc23 mentioned that they use their internal Gitlab as a package registry:
  • General: https://docs.gitlab.com/ee/user/packages/package_registry/
  • Composer: https://docs.gitlab.com/ee/user/packages/composer_repository/

My understanding is:

• The 'registry' feature has to be enabled on all projects (by default, it is, and when we create projects via civicrm.org, we can also make sure that it is enabled)
• We can publish packages to the registry using the Gitlab API, so the extdir module on civicrm.org, when a new version is tagged, could publish to the registry, without having each extension setup CI/CD (which would not be that hard, but not super convenient either, since there are probably 100+ active extensions on Gitlab)
• Extensions must use a valid composer version, such as X.Y.Z. This will be a bit of a pain to get people to change their habits, since many do not (I know I often didn't bother). We would have to modify the extdir validation and update docs, blog, etc, because devs will complain. Worst case, for less active extensions, we can use dev-master (at least, that's what I do, because many extensions are in maintenance-only mode), or we (extension group admins) can tag new releases for extensions on Gitlab.
• Site admins using composer: need to add the repository to their composer config (example below), but wouldn't need to specify each extension git repo

Gitlab say that the feature is beta, and it's not clear those bugs would have an impact on us:
https://gitlab.com/groups/gitlab-org/-/epics/6817

Example: I tested with the invoicehelper extension:

curl --fail-with-body --data tag=2.1.0 "https://__token__:glpat-[...redacted...]@lab.civicrm.org/api/v4/projects/313/packages/composer"
{"message":"201 Created"}

Then in a composer project, I did:

composer config repositories.58 composer https://lab.civicrm.org/api/v4/group/58/-/packages/composer/packages.json
composer require civicrm/invoicehelper:^2

It was slow, but it worked.