Introduce support for auto-creation of user referenced in remoteUser or containerUser properties

[Chuxel]

This proposal is an offshoot of discussions related to refactoring the "common script" currently housed in the microsoft/vscode-dev-containers repository.

A frequent area of confusion for dev containers is how to create a non-root user for a container. In addition, developers will sometimes add a containerUser or remoteUser property to their devcontainer.json and expect it to be created.

This led to the common script and all related images built out of the vscode-dev-containers repository having the logic to add a non-root user built into it. Overall, this has worked pretty well. However, Dev Container Features (#61) also need to adapt to the presence of a non-root user to set permissions. Existing Features in the vscode-dev-containers repository include automated logic to attempt to auto-detect a non-root user. But the process has the potential to not detect correctly and it increases the complexity of each. Furthermore, it also means that the common script always needs to fire first in the Feature build order - which is not ideal.

All of this indicates that we should consider user generation a core part of the dev container spec. There are three things here:

1. Create a user if one with the specified name does not exist
2. Optionally install and configure sudo for the user
3. Optionally set up sudo to not require a password for the user ("passwordless")

To support all three of these, we can support an object syntax in addition to the current string format. E.g.,

{
    "remoteUser": {
        "name": "devcontainer"
        "create": true,
        "sudo": "password" // Other options are "none", "passwordless"
    }
}

The existing string format would default to the above values:

{
    "remoteUser": "devcontainer"
}

We could use "passwordless" as the sudo default, but it likely makes sense to stick with a secure default here given the new semantics. Sudo could be installed by default, but the user would need to set a password to start using it in this case.

In addition, Dev Container Features should have an environment variable passed into them with the value of containerUser and remoteUser so that they can adapt without their own detection logic.

CONTAINER_USER=root
REMOTE_USER=devcontainer

We could also consider expanding #25 into the user create scenario as a way to fire scripts to update things like permissions when this user is created.

//cc @alexdima @chrmarti @jkeech @samruddhikhandale @joshspicer

[bamurtaugh]

What is the scenario where a user would set "create": false?

[Chuxel]

Permissions may also be set up for other folders for a specific user in the upstream image, and if you create one automatically, certain things wouldn't work for this new user, so setting this to false would ensure that if someone just tweaked the name because they wanted a different one, they wouldn't get a non-functional user.

There are also some security implications to creating users - I think it makes sense to be able to disable this behavior even if the default is to create one. I can see situations where orgs or teams may not want one to be inadvertently created with different settings than what they would add manually. That said, if folks felt strongly about not including it, we could probably get by without to start.

[Clockwork-Muse]

How about a list of user groups to add?

{
    "remoteUser": {
        ...
        "groups": ["audio", "video", "plugdev"]
    }
}