Cherry-pick #41724

- What I did

Fixes #41723

When building images in a user-namespaced container, v3 capabilities are
stored including the root UID of the creator of the user-namespace.

This UID does not make sense outside the build environment however. If
the image is run in a non-user-namespaced runtime, or if a user-namespaced
runtime uses a different UID, the capabilities requested by the effective
bit will not be honoured by execve(2) due to this mismatch.

Instead, we convert v3 capabilities to v2, dropping the root UID on the
fly.

- How I did it

Patched ReadSecurityXattrToTarHeader() to automatically convert v3 capabilities to v2 by switching the version identifier and dropping the root UID data.

- How to verify it

This reproducer can be used.

Compared with the output in issue #41723 this produces:

    default: + docker run --rm capabilities-built-with-no-userns:1.0 /bin/bash -c '(/usr/local/bin/sleep-test infinity & ); sleep 1; grep Cap /proc/$(pgrep sleep-test)/status'
    default: CapInh:	00000000a80425fb
    default: CapPrm:	0000000000000400
    default: CapEff:	0000000000000400
    default: CapBnd:	00000000a80425fb
    default: CapAmb:	0000000000000000
    default: + docker run --rm capabilities-built-with-userns:1.0 /bin/bash -c '(/usr/local/bin/sleep-test infinity & ); sleep 1; grep Cap /proc/$(pgrep sleep-test)/status'
    default: CapInh:	00000000a80425fb
    default: CapPrm:	0000000000000400
    default: CapEff:	0000000000000400
    default: CapBnd:	00000000a80425fb
    default: CapAmb:	0000000000000000

So we see that in the 2nd case also execve(2) honoured the effective bit.

- Description for the changelog

Capabilities in image layers are stored in v2 format even when built inside a non-root user-namespace.

- A picture of a cute animal (not mandatory but encouraged)