collector/filesystem: fix readonly false positives under ro rootfs bind mount

[locker95]

Fixes #3755

The regression

After upgrading from 1.11.x to 1.12.0/1.12.1, node_filesystem_readonly reports 1 for host filesystems that are clearly writable, when node_exporter runs in the recommended containerized deployment (-v /:/host:ro,rslave + --path.rootfs=/host).

Root cause

isFilesystemReadOnly() (introduced for #3157/#3484) considers a filesystem read-only when either the per-mount options (mountinfo field 6) or the super options (last mountinfo field) contain ro:

• v1.11.x: mountOptionsString() concatenated the options map without separators (e.g. ro,relatime became rorelatime), so strings.Split(opts, ",") could never match ro alongside other options. The per-mount check was effectively dead — that hid this problem (while also causing node_filesystem_readonly does not report readonly bind mounts correctly #3484).
• v1.12.0: 65902fa (fix(filesystem): add comma separator in mountOptionsString #3659) fixed the missing comma separator, so the per-mount ro check actually started matching.

In the recommended containerized deployment the host root is bind-mounted read-only into the container. On current Docker (25.0+/API 1.44+, kernel >= 5.12) ro bind mounts are recursively read-only, so every host mount propagated via rslave carries a per-mount ro flag in the exporter's mount namespace — even though the filesystems are writable on the host. Unless the container also runs with --pid=host (in which case /proc/1/mountinfo provides the host's view), the exporter reads its own namespace's mountinfo and now reports readonly 1 for every host filesystem. That is exactly the reporter's setup in #3755, and the same false positive was previously observed with the statfs-based detection in #2506.

The per-mount ro seen through --path.rootfs describes the exporter's own view of the host mounts (an artifact of the deployment), not the state of the host filesystem.

The fix

For mount points below the configured --path.rootfs prefix, only consider the super options for the read-only decision. The superblock is shared across mount namespaces, so ro/emergency_ro there reliably reflects the state of the host filesystem regardless of how the exporter observes it:

• Host filesystems observed through a read-only bind mount are no longer falsely reported (superOptions=rw, per-mount ro ignored) — fixes the regression.
• Truly read-only filesystems are still reported: superblock ro (e.g. mount -o ro, or an ext4 emergency remount triggered by errors=remount-ro) and emergency_ro (Linux 6.15+, filesystem: support ext4 super block emergency_ro flag #3717) are honored for host mounts.
• Deployments without a rootfs prefix (bare metal, or containers with --pid=host where mountinfo is read from the host's PID 1) are unchanged: the per-mount ro semantics from node_filesystem_readonly does not report readonly bind mounts correctly #3484 (read-only bind mounts of a writable device) are preserved.

Tests

• New fixture collector/fixtures_bindmount_ro/ mirrors the reporter's environment as seen from the container's mount namespace: /host and /host/var/data with per-mount ro but superblock rw (must be 0), plus a superblock-ro mount and an emergency_ro mount under /host (must stay 1), and a ro bind mount of the container itself outside the rootfs prefix (must stay 1, node_filesystem_readonly does not report readonly bind mounts correctly #3484 semantics).
• TestPathRootfsReadOnly runs mountPointDetails + isFilesystemReadOnly against that fixture. It fails on current master (/ and /var/data are reported read-only) and passes with this change.
• New hostMount cases in Test_isFilesystemReadOnly cover the unit-level behavior.

Verified locally with GOOS=linux go build, GOOS=linux go vet and GOOS=linux go test -c (development on a non-Linux host — the Linux test suite runs in CI).