Key Request Service (Documentation/security/keys/request-key.rst) unable to perform upcalls

### Windows Version

Microsoft Windows [Version 10.0.22631.3520]

### WSL Version

0.0.0.0

### Are you using WSL 1 or WSL 2?

- [X] WSL 2
- [ ] WSL 1

### Kernel Version

5.15.150.1

### Distro Version

Debian 12.2.0

### Other Software

keyutils-1.6.3 (Built 2022-12-18)

### Repro Steps

The keyutils key request service documented in Documentation/security/keys/request-key.rst is used for management of keyrings as as well as dns resolution and id mapping. The key request service executes /sbin/request-key which performs the requested operation.

Reproduction of the failure can be performed by executing

1. keyctl request2 user debug:foo "expired" @s

### Expected Behavior

If the upcall succeeds /sbin/request-key will have been launched and key named "foo" will be visible within the /proc/keys output.

1. grep foo /proc/keys

### Actual Behavior

The /sbin/request-key process is not executed and "keyctl request2" fails with `request_key: No such file or directory`.

The underlying problem is that "/sbin/request-key" cannot be found.
`# keyctl request2 user debug:foo "expired" @s
request_key: No such file or directory`

The underlying problem appears to be that /sbin/request-key and its configuration /etc/request-key.conf are present in the WSL2 container's root filesystem and not the filesystem of the underlying host.

`$ ls -l /sbin/request-key
-rwxr-xr-x 1 root root 26952 Dec 18 2022 /sbin/request-key`

Without a functioning key request service it is not possible to keyrings, nfs, cifs, afs, id mapping, and other services that rely upon the key request service cannot properly function.

I'm not sure if the fix is for WSL2 to install keyutils as part of the host root filesystem or for the Linux kernel to be patched to execute /sbin/request-key from the container's root filesystem.

### Diagnostic Logs

Diagnostic logs should not be required to reproduce this issue. Prior bug reports such as https://github.com/microsoft/WSL/issues/9540 are the same as this report but were closed due to inactivity.

Start with Documentation/security/keys/request-key.rst and reproduce the keyctl request2 failure described for WSL 2 on Debian 12. Compare the documented upcall behavior with the locations of /sbin/request-key and /etc/request-key.conf, then determine the supported resolution and verify that the request-key service can complete the reported operation.

Written by the indexing model from the issue text.