[fix](be) fix disk metrics staying empty on LVM/device-mapper mounts

[sinhaparth5]

What problem does this PR solve?

Issue Number: close#62365

Problem Summary:

BE disk metrics come back empty when a data dir sits on an LVM (device-mapper) volume.

DiskInfo::get_disk_devices() in be/src/util/disk_info.cpp looks up a mount's device by comparing basenames: it takes the device column from /proc/mounts, strips trailing digits (sda2 -> sda), and checks that name against the table get_device_names() built from /proc/partitions. For an LVM mount, /proc/mounts shows /dev/mapper/<vg-lv>, which never matches the dm-N name /proc/partitions uses, so the lookup always fails and no per-disk metrics get installed for that mount.

get_device_names() already builds _s_device_id_to_disk_id, a table keyed by the device's real dev_t (major:minor), for exactly this kind of lookup. get_disk_devices() just wasn't using it. This PR resolves the mount's device with stat() and matches on st_rdev against that table instead of comparing names.

Also stopped trimming trailing digits off dm-N names in get_device_names(). For a regular disk the digits mark a partition (sda1, sda2 are both sda), but for device-mapper the number identifies a distinct logical volume, not a partition, so dm-0 and dm-1 were being collapsed into one bogus dm- entry.

Added be/test/util/disk_info_test.cpp covering the extracted DiskInfo::strip_partition_suffix helper.

Release note

None

Check List (For Author)

• Test
  • Unit Test
  • Manual test (add detailed scripts or steps below)

Manual test: hand-traced the /proc/mounts / /proc/partitions parsing against a real LVM layout (/dev/mapper/vg-lv0 mounted, backed by dm-0) to confirm the new stat()-based match resolves correctly, plus the new unit test for strip_partition_suffix. Also running the BE unit test build on a separate box to confirm DiskInfoTest.* passes; will update this PR when that finishes.

• Behavior changed:

  • No.
  • Yes. Disk metrics now populate for data dirs on LVM/device-mapper mounts, which previously stayed empty.

• Does this need documentation?

  • No.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?