fix(devinfo): add consistent read for kernel bug

[niladrih]

Fixes openebs/mayastor#1274

On the linux kernel versions below v5.8, there's a bug which behaves like so:
Whenever a read(2) syscall is issued (and this one takes an argument for how many bytes to read off of a file) to the /proc/mounts virtual file, few of the mount entries are read off of it. The kernel maintains the seek position of the file so that it can serve subsequent read(2)s from that position. But, in between the first and the second read(2), a device might be unmounted and one/few mount entries might be removed from the already-read portion of the file. This moves the mount entries after the deleted entries further up the file. However, the seek position has not changed. So, subsequent read(2)s will miss one or more read entries, as the seek position now points to a mount entry further down the list.
Ref: torvalds/linux@9f6c61f

Changes:
This PR adds a consistent_read() implementation for the interface MountIter for kernel versions less than 5.8.0. consistent_read() reads the whole file twice start to end, and compares the two byte buffers. If both of the subsequent reads resulted in the same byte-sequence, then we can say we have not lost mount entries when traversing /proc/mounts, as then the comparison would fail on the second read from start to end. This is configured to default to 2 comparison retries if the first comparison fails. However that may not be enough if there are very many mount entries and the host has very frequent unmounts. Use higher retries for those cases.

[niladrih]

@tiagolobocastro and others -- should I remove the MountIter::new() API as I intend to refactor control-plane and mayastor to use SafeMountIter instead?

[niladrih]

Is the linter CI issue because of std::sync::OnceLock?

[tiagolobocastro]

Is the linter CI issue because of std::sync::OnceLock?

Non-related, @datacore-vvarakantham is fixing this

[tiagolobocastro]

@tiagolobocastro and others -- should I remove the MountIter::new() API as I intend to refactor control-plane and mayastor to use SafeMountIter instead?

We need to keep I think, otherwise you can't merge this PR independently to the other repos?

[niladrih]

@tiagolobocastro and others -- should I remove the MountIter::new() API as I intend to refactor control-plane and mayastor to use SafeMountIter instead?

We need to keep I think, otherwise you can't merge this PR independently to the other repos?

Yeah, it's fine to keep it.