Get GDK/Workspaces into Early & General Availability for Community Contributors

In #645, we created a workspaces cluster for use by community contributors. We have built the provisioning of the workspaces into this project.

The following steps are outstanding from this effort:

• A regular build of the container based on the gdk-in-a-box:main image
• Regular pulling of the 'latest' image to cluster nodes - in order to speed up workspace creation time. Note that we need to be wary of 'filling the disk' of these nodes with images. We need to investigate a method to 'purge' old unused images.
• A dashboard to understand usage (based off of gitlab-org/quality/engineering-productivity-infrastructure!1050)
• User control. Gating user access to workspaces see note below
  • 'Formalize' existing ad-hoc users into a group
  • Add 'request access' functionality
  • Add gating cross-reference to contributor platform
• Docs - make this discoverable and part of our general contributor docs. (This includes 'how to gain access' and other criteria)

Why

We want to enable contribution from our community, regardless of their limitations on hardware or what they can and can't run on their machines. This project allows contributors to spin up a working GDK in minutes, using the GitLab Workspaces feature, hosted by GitLab.

Gating user access

Ideally, we want to give access to all contributors. That said, we need to tread even more carefully than with CI resources, as we're directly giving "random people" access to compute, provided by GitLab.

We can do this (following our value of assume positive intent) by granting access in a layered fashion.

Initially, granting access on an ad-hoc basis (early testers, and those co-creates where we've used workspaces) (already done, needs 'formalization' into a reusable user group)

Once we're past that, we could use a contributor's level as a gate - initially level 4 (experienced contributors are more likely to be able to 'cope with' any issues), but gradually lowering the criteria as we begin to build a picture of scale and resource usage. Doing this side-by-side with a 'request and approve' process should give us flexibility to grant ad-hoc access as well as more general access.

Checking against a contributor's level would require automation to 'cross reference' the user to the contributor platform. As of writing this, I'm not sure what api support already exists, but it should be 'relatively easy' to add the required support if it isn't there.