support native volume bind in another WSL distribution

[bingoct]

Is your feature request related to a problem? Please describe

support native volume bind in another WSL distribution.

# 
➜ docker run -v /home/bingo/myWork:/myWork  --rm busybox:latest ls /myWork
Error: statfs /home/bingo/myWork: no such file or directory

# using windows mount as temporary solution
➜ mkdir -p /mtn/d/d12/mywork && sudo mount --bind  /mnt/d/d12/myWork /home/bingo/myWork
docker run -v /mtn/d/d12/mywork:/myWork  --rm busybox:latest ls /myFolder

Describe the solution you'd like

As seen previously with Docker Desktop, effortlessly integrating selected WSL environments became feasible after specifying respective WSL contexts If it aligns with future plans, incorporating analogous capabilities within Podman would undoubtedly prove beneficial to wsl users, myself included.

Describe alternatives you've considered

At present, mitigation efforts involve sharing volume in WSL through the Windows host at /mnt, thus allowing interaction via the podman remote tool across distinct WSL environments. However in this method, there is bound to be a noticeable decline in both reading and writing performance compared to directly engaging with the \\wsl$ drive. Moreover, manual steps involving switching working directories is very inconvenient.

It is possible to store your project files on a mounted drive, but your performance speed will improve if you store them directly on the \wsl$ drive.

Additional context

refer:

• https://podman-desktop.io/docs/podman/accessing-podman-from-another-wsl-instance
• https://github.com/containers/podman/discussions/13537
• https://learn.microsoft.com/en-us/windows/wsl/filesystems#file-storage-and-performance-across-file-systems

[benoitf]

moving to podman repository

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.