Don't swallow IOException

Don't swallow IOException

Swallowing intermittent errors and trying to recover from them
makes JGit's behavior hard to predict and difficult to debug.

Propagate the errors instead.  This doesn't violate JGit's usual
backward compatibility promise for clients because in these
contexts an IOException indicates either repository corruption or
a true I/O error.  Let's consider these cases one at a time.

In the case of repository corruption, falling back e.g. to an empty
set of refs or a missing ref will not serve a caller well.  The
fallback does not indicate the nature of the corruption, so they are
not in a good place to recover from the error.  This is analogous to
Git, which attempts to provide sufficient support to recover from
corruption (by ensuring commands like "git branch -D" cope with
corruption) but little else.

In the case of an I/O error, the best we can do is to propagate the
error so that the user sees a dialog and has an opportunity to try
again.  As in the corruption case, the fallback behavior does not
provide enough information for a caller to rely on the current error
handling, and callers such as EGit already need to be able to handle
runtime exceptions.

To be conservative, keep the existing behavior for the deprecated
Repository#peel method.  In this example, the fallback behavior is to
return an unpeeled ref, which is distinguishable from the ref not
existing and should thus at least be possible to debug.

Change-Id: I0eb58eb8c77519df7f50d21d1742016b978e67a3
Signed-off-by: Jonathan Nieder <jrn@google.com>