Investigation: Use Kubernetes User Namespaces to provide container build and run capability inside workspace
MR: Pending
<!--
The first line of the MR must be one of the following:
1. `MR: Pending`
2. `MR: <MR link with trailing +>`,
and the first description line of the MR should be `Issue: <Issue link with trailing +>`
3. `MR: No MR`
For more context, see:
https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs
-->
<!--
The following sections should be filled out as part of the refinement process before the issue is prioritized.
For more context, see:
https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting
-->
## Description
As a user, I want build and run container images inside my workspace so that I can perform normal development activities that I would do on my local machine.
Kubernetes has an alpha feature of user namespaces in pod which allows you to securely run as root within the container.
- https://www.youtube.com/watch?v=YmbCfeVPHEI
- https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/
- https://kubernetes.io/docs/tasks/configure-pod-container/user-namespaces/
- https://kubernetes.io/blog/2024/04/22/userns-beta/
- https://kubernetes.io/blog/2023/09/13/userns-alpha/
- https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/
- https://www.redhat.com/sysadmin/introduction-crun
- https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md
- https://www.cncf.io/online-programs/power-to-the-people-making-root-docker-a-reality-inside-a-gitpod-container/
- https://youtube.com/watch?v=uRp0YltujVE
## Acceptance Criteria
- [ ] [Describe what must be achieved to complete this issue.]
- [ ] [Describe another requirement needed to complete this issue.]
- [ ] [Add additional acceptance criteria as needed.]
## Technical Requirements
TODO: Fill out or delete
[If applicable, please list out any technical requirements for this feature/enhancement.]
## Design Requirements
TODO: Fill out or delete
[If applicable, please provide a link to the design specifications for this feature/enhancement.]
## Impact Assessment
TODO: Fill out or delete
[Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.]
## User Story
TODO: Fill out or delete
[Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.]
<!-- Replace with other type, e.g. bug or maintenance, if appropriate -->
<!-- Replace with other subtype if appropriate -->
<!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process -->
<!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->
issue