feat: show Btrfs subvolumes

[horror-proton]

Show Btrfs subvolumes as underlined blue text.
A similar version was implemented in #53 , but not been merged as in #167 .

Some questions:

I came up with two ways to tell if a file is in Btrfs,

1. Searching for parent directory recursively in /proc/mounts

• Mounted filesystems are already listed, no extra operation required.
• May not be fully reliable (e.g. in some filesystem namespace such as a container or bwrap, procfs may not even exist)

  [@ArchLinux] > bwrap --symlink /usr/lib64 /lib64 --ro-bind /usr /usr findmnt
  findmnt: can't read /proc/mounts: No such file or directory
  

2. Using glibc's statfs and check f_type

• Requires an extra statfs syscall
• Kernel also reads out many other information, such as capacity. Could affect performance?
• Benefit from cache mechanism of pathname lookup in kernel? I don't know.

I'm not sure which one is better and how to benchmark.

Here I just kept them both and the second one only works as a fallback.

I have no idea how all the theming works, I just copy the codes from mount_point.

[cafkafk]

I'm not sure which one is better and how to benchmark.

you can run a version with and without changes on a couple of different directories with a bunch of flags using hyperfine and see if it indicates stuff getting slower

[daviessm]

I'm the contributor of #53 and #167, for the record I'm glad someone did this - I just haven't had time (read: I'm too lazy). Hope to see it merged!

[MartinFillon]

lgtm

[horror-proton]

I ran some simple tests on a loop device formatted into Btrfs,

> ls -lah
drwxr-xr-x ... 0
lrwxrwxrwx ... dir -> 0/0/0/0/0/0/0/0/0/0
> cd dir
> seq 1000 | xargs btrfs subvolume create

Searching for parent mountpoint recursively:

Benchmark 1: eza -lah --mounts .
  Time (mean ± σ):      22.6 ms ±   1.5 ms    [User: 35.4 ms, System: 10.0 ms]
  Range (min … max):    19.8 ms …  30.7 ms    118 runs

statfs syscall:

Benchmark 1: eza -lah --mounts .
  Time (mean ± σ):      16.9 ms ±   1.4 ms    [User: 32.3 ms, System: 10.9 ms]
  Range (min … max):    14.2 ms …  22.3 ms    170 runs

Do nothing and return false:

Benchmark 1: /tmp/eza/target/debug/eza -lah --mounts .
  Time (mean ± σ):      16.7 ms ±   1.4 ms    [User: 33.0 ms, System: 11.3 ms]
  Range (min … max):    13.5 ms …  20.5 ms    185 runs

[daviessm]

You'll probably need to test with a few (hundred) thousand more, as well as nested directories, nested subvolumes, and if possible slow (HDD) devices for each of the options.

[horror-proton]

My laptop has no HDD attached to it, so I'm using dmsetup to simulate a device with 20ms of delay based on the same loop device.
The first ls attempt took 16 seconds !!!, however the following benchmarks had almost the same result as the ones on a normal loop device (24ms and 17ms).
Presumably the kernel has caching mechanism for files and filesystem info. I'm not sure if the result also applies to a real word situation, for the test filesystem is significantly smaller than my memory.