Don't handle FNF exceptions when reading snapshot

[s1monw]

We used to handle FNF exceptions in the store when reading a snapshot.
For instance if we can't open a segments file for a given commit point
we just return an empty metadata object and tracelog the even. This can
cause shards to be false marked as corrupted if a shard is forcefully
removed while a recovery started at the same time. We should in general
bubble up these exceptions and let the caller decided how to handle the
IOExceptions.

[bleskes]

The change looks good, but I'm worried about the implication it has for recovery as we use the same api to list the files already available on the local directory. I'm not sure if FNF can be thrown in that cause, but I think we should be safe.

I'm working on a change to the recovery code that will give us better protection in that case, after which we can pull this in? (PR Coming)

[bleskes]

Here is the PR mentioned: #8092

[bleskes]

I'm not sure if FNF can be thrown in that cause, but I think we should be safe.

It turns out this is not a concern because when listing local files on a recovery target we do not supply a commit point but rather pass a null to Store.readSegmentsInfo(commit, directory). In this case it try to find a commit point but not throw a FNF if none was found.

LGTM