libmount: handle failure to apply flags as part of a mount operation

libmount: handle failure to apply flags as part of a mount operation

If a mount operation with extra flags runs into an EPERM when applying
the flags, then mnt_context_get_mount_excode() returns 'Unknown error
5005' and MNT_EX_FAIL.  Here's an example:

Create a mount point on the host with 'nodev,nosuid,noexec':
  $ dd if=/dev/zero of=/var/tmp/loopfile bs=40960 count=1024
  $ sudo losetup --find /var/tmp/loopfile
  $ sudo mkfs.ext4 /dev/loop0
  $ sudo mkdir /mnt/a
  $ sudo mount -o nosuid,nodev,noexec /dev/loop0 /mnt/a

Check the mount options to be sure:
  $ findmnt --output OPTIONS,PROPAGATION /mnt/a
  OPTIONS                                  PROPAGATION
  rw,nosuid,nodev,noexec,relatime,seclabel shared

Enter a mount and user namespace:
  $ podman run \
        --interactive \
        --privileged \
        --rm \
        --tty \
        --volume /:/run/host:rslave \
        registry.fedoraproject.org/fedora:38 \
        /bin/bash

Try to bind mount the mount point from the host inside the namespace
with some extra flags:
  # mkdir ~/b
  # mount --bind -o ro /run/host/mnt/a ~/b
  mount: /root/b: filesystem was mounted, but any subsequent operation
      failed: Unknown error 5005.
  # echo $?
  32

It will be better to show something more human-readable than 'Unknown
error 5005'.

Secondly, an exit code of 32 means 'mount failure', which isn't quite
correct here.  The mount operation is split into two mount(2) calls,
where the first one uses MS_BIND to create the bind mount, and the
second uses MS_REMOUNT | MS_BIND | MS_RDONLY to apply the 'ro' flag.
Here, the first mount(2) does succeed:
  # findmnt --output OPTIONS,PROPAGATION ~/b
  OPTIONS                                  PROPAGATION
  rw,nosuid,nodev,noexec,relatime,seclabel private,slave

It's only the application of the 'ro' flag with the second mount(2) that
fails with an EPERM.  Hence, an exit code of 1 that means 'incorrect
invocation or permissions' seems more appropriate.

Signed-off-by: Debarshi Ray <rishi@fedoraproject.org>