save-cmd: progress meter wouldn't count identical files correctly.

save-cmd: progress meter wouldn't count identical files correctly.

This one was really tricky.  If a file was IX_HASHVALID but its object
wasn't available on the target server (eg. if you backed up to one server
server and now are backing up to a different one), we could correctly count
is toward the total bytes we expected to back up.

Now imagine there are two *identical* files (ie. with the same sha1sum) in
this situation.  When that happens, we'd back up the first one, after which
the objects for the second one *are* available.  So we'd skip it, thinking
that we had skipped it in the first place.  The result would be that our
backup count showed a final byte percentage less than 100%.

The workaround isn't very pretty, but should be correct: we add a new
IX_SHAMISSING flag, setting or clearing it during the initial index scan,
and then we use *that* as the indicator of whether to add bytes to the count
or not.

We also have to decide whether to recurse into subdirectories using this
algorithm.  If /etc/rc3.d and /etc/rc4.d are identical, and one of the files
in them had this problem, then we wouldn't even *recurse* into /etc/rc3.d
after backing up /etc/rc4.d.  That means we wouldn't check the IX_SHAMISSING
flag on the file inside.  So we had to fix that up too.

On the other hand, this is an awful lot of complexity just to make the
progress messages more exact...