Add container and scripts for Remote Dev

What does this merge request do and why?

(Follow on from !3215 (merged))

This creates a container that can be used for gitlab/GDK Remote Development.

Related to #1857 (closed)

Related to gitlab-org/developer-relations/contributor-success/team-task#254 (closed)

What/how its done

Container build

1. Starts by cloning GDK into a /workspace folder.
2. Inside that folder, it runs make bootstrap to install dependencies, including asdf
3. GDK is then installed with a shallow clone (this seeds the database and seeds clones of the projects)
4. The gitlab clone is then removed (we will clone this later, when running the container)
5. The GDK folder is moved to one side. (${HOME})

Workspace creation/startup

1. When the workspace starts up, it will use a directory of /projects/${PROJECT-PATH}
2. As part of initialisation, there is an initcontainer that clones the repository you're running the workspace on.
3. After startup, you will have a 'fresh' clone of GDK in /projects/${PROJECT-PATH}

Workspace support script

1. Reconfigures GDK with (dynamic) values we now have on hand
2. Checks to see you have fs.inotify.max_user_watches set. (This needs to be set at the cluster level - the running workspace container doesn't have the privileges to do so)
3. Clones gitlab
4. Copies items from the container-provided/bootstrapped/installed GDK folder (in ${HOME}) to the /projects/${PROJECT-PATH} GDK
5. Runs a gdk reconfigure
6. Installs any gems
7. Migrates the bootstrapped database
8. Runs a gdk update (This helps ensure items are rebuilt with the correct paths)

How to set up and validate locally

This is now available as an image in this project: registry.gitlab.com/gitlab-org/gitlab-development-kit/gitlab-remote-workspace:stingrayza-gdk-remote-dev-add-container (tag based on the branch name)

1. Set up a cluster for workspaces
2. Ensure your cluster has fs.inotify.max_user_watches set
3. Use a fork of GDK with a .devfile.yaml in the root directory of the main branch (example)
4. Start a workspace using your project and cluster
5. From within your workspace, run support/gitlab-remote-dev/remote-dev-gdk-bootstrap.sh
6. Sit back and wait for GDK to start, when successful, the script will output a link to your running GDK

Impacted categories

The following categories relate to this merge request:

• gdk-reliability - e.g. When a GDK action fails to complete.
• gdk-usability - e.g. Improvements or suggestions around how the GDK functions.
• gdk-performance - e.g. When a GDK action is slow or times out.

Merge request checklist

• This change is backward compatible. If not, please include steps to communicate to our users.
• Tests added for new functionality. If not, please raise an issue to follow-up.
• Documentation added/updated, if needed.
• Announcement added, if change is notable.
• gdk doctor test added, if needed.
• Add the ~highlight label if this MR should be included in the CHANGELOG.md.