Docker containers: use node binary installed inside the container for running actions

This feature request is related to:

• https://github.com/actions/checkout/issues/334
• and somewhat related to #1011

Context

When using - for example: actions/checkout@v2 - in a workflow then it requires node to run.
The runner does attempt to provide for this and it does this by using a volume mount with target dir /__e/.
This directory contains:

• node12/bin/node and node16/bin/node; these are 64-bit binaries linked with glibc (or at least that's what I assume, not 100% verified)
• node12_alpine/bin/node and node16_alpine/bin/node: these are 64-bit binaries linked with musl (or at least that's what I assume, not 100% verified)

This is not always sufficient: when deploying a 32-bit(/i386) docker container then it needs a 32-bit node.
There are only 64 binaries in /__e/ and one of those is used; that does not work and results in a somewhat cryptic error.[^1]

Several solutions are possible:

• also let the host-runner provide a 32 node binaries and adapt the code to check if a 32/64 container is used. I think #1011 is about that;
• require node to be installed in the container; this is what this feature request is for.

Describe the enhancement

Today: when an action is run node installed in /__e/ is used, this does not always work (see above).

What I would like: make it possible to use node that is installed inside the container.
This should make it possible to install a 32-bit node inside a 32-bit container and running it - via docker - on a 64-bit host.

Code Snippet

Links to the relevant code:

• Checking for Alpine: https://github.com/actions/runner/blob/main/src/Runner.Worker/Handlers/StepHost.cs#L156
  This code attempts to check if the container is running a version of Alpine or something else.
  I'm assuming it does this check because Alpine is using musl as libc (and not glibc).

• Setting the path of the node binary: https://github.com/actions/runner/blob/main/src/Runner.Worker/Handlers/NodeScriptActionHandler.cs#L115
  This code constructs the fully-qualified-path to the node binary, which - currently - is always a path in /__e/.

Additional information

Another nice-to-have (but I suppose that could be a separate feature request): before attempting to run an action that requires node attempt to run node --version inside the container and if that fails provide an error message indicating that node is not usable.

[^1]: Error in that case: OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: no such file or directory: unknown

Start by reading Runner.Worker/Handlers/StepHost.cs around the Alpine check and NodeScriptActionHandler.cs around line 115, then trace how Docker action containers are launched. Determine how a container-installed Node binary can be selected for Node actions while preserving existing Alpine handling. Done means a 32-bit container can run its own Node binary instead of the host-mounted binary.