[Idea]: add status/progress bar when checking existing data on receiving side

[dlong500]

What happened?

When resuming a large transfer there is nothing shown on either the sending or receiving side while an existing file is being "checked" (unless debug mode is on). This can take a LONG time. It may seem like the process is hung or something else is going wrong with no status being shown.

What did you expect to happen?

Ideally a status message that a particular file is being checked (or even a progress bar like shown when a file is being hashed initially) should be shown on both sides.

Steps to reproduce

1. Initiate a large file transfer (in my case 80GB) without any debug
2. Abort the transfer process halfway through
3. Re-initiate the transfer of the same data
4. Watch as the sending/receiving sides show no status while the existing data is being checked
5. Finally see the process continue as normal once the check is finished

croc version

10.3.1

Operating System

Other (please specify in additional context)

OS Version

Applies to all OS/versions

Relevant log output

Additional context

If I get the time I could try to submit a PR, but this may be a simple thing to add since you already show progress bars for several other operations.

[dlong500]

As a follow-up, I did eventually find a couple previous issues that mentioned similar things, but the response was usually just "use imohash" to speed up the hashing step. I have serious concerns about a hashing algorithm that only samples the file in the context of a remote file transfer. There are too many things that can go wrong (faulty ram, OS/software bugs, network glitches) that would lead to bad data. Hashing the full contents in this context is important for data integrity.

However, things could be a lot clearer if, during a receiver-side hash check on existing data, the sender side shows a message like File XYZ is being checked on receiver... and the receiver side showed a progress bar like what is shown on the sender side when initiating a transfer.

Also, there could be an option for caching of hashes on the sender side for the purpose of resuming file transfers without having to recalculate each and every attempt (especially for flaky connections that get interrupted a lot).

This isn't just a problem in theory. I currently have an 80GB file that croc says is the same when using imohash, but is actually not identical. I'm falling back to the standard xxhash algorithm and (via debug mode) I can see it did detect the difference--but currently waiting to see if croc can handle actually fixing the difference. It took 20 minutes or so for the hash to determine the file is not equal, now it states working on file 0.