Fix relabeling local volume source dir

[kolyshkin]

- What I did / - How I did it / - How to verify it
In case a volume is specified via Mounts API, and SELinux is enabled,
the following error happens on container start:

$ docker volume create testvol
$ docker run --rm --mount source=testvol,target=/tmp busybox true
docker: Error response from daemon: error setting label on mount
source '': no such file or directory.

The functionality to relabel the source of a local mount specified via
Mounts API was introduced in commit 5bbf5cc (#34684) and later broken by commit
e4b6adc (#36688), which removed setting mp.Source field.

With the current data structures, the host dir is already available in
v.Mountpoint, so let's just use it.

Fixes: e4b6adc

- Description for the changelog

Fix relabeling of local volumes specified via Mounts API on selinux-enabled systems

[thaJeztah]

Some quick thoughts / questions (didn't dig into the whole code flow 😅);

• IIRC, when using the mount API, relabelling is disabled for bind-mounts (i.e., it's only accepted for volumes); is that still the case with this change?
• Apparently, our tests didn't catch this regression; is it possible to write a test for this, to verify that labelling works?

[thaJeztah]

also; ping @cpuguy83 PTAL

[mavenugo]

The janky failure : DockerSwarmSuite.TestSwarmLockUnlockCluster is a known flaky failure.

[mavenugo]

LGTM

[kolyshkin]

IIRC, when using the mount API, relabelling is disabled for bind-mounts
(i.e., it's only accepted for volumes); is that still the case with this change?

I am not touching any non-volume code here so there should be no change.

is it possible to write a test

I thought about that and can't think of any good unit test since the code and data are spread among the different subsystems. I can try adding an integration test though.

[thaJeztah]

let's work on (e2e) tests in a follow up

LGTM