Investigate fetch and gvfs-helper

[jeffhostetler]

In #240
an issue was uncovered where a git fetch would try to use gvfs-helper prefetch (to the cache-server), receive 0 new objects, and then try a remote-https / fetch-pack directly to the origin server. This would fail because a gvfs-aware origin server does not allow normal fetches and requires use of the gvfs-protocol. This server error prevented fetch from attempting a gvfs-style missing object (either individual or batch) fetch. The behavior of gvfs-helper seems to be slightly different from the original read-object-hook in this regards.

The fix in #240 does address the problem.

The purpose of this issue is to investigate performance. This has only been observed when the origin server is ahead of the cache server. So the ref exchange may have very new objects that are not yet present on the cache server. It seems like we might:
[1] either have gvfs-helper do the fallback to main when it receives a 0 object prefetch from the cache-server. this might prevent the foreground fetch from needing to run the fetch-pack at all.
[2] have fetch do the second prefetch to the main server (rather than hiding it inside gvfs-helper).
[3] other??

My concern here is that the individual missing object fetches following the (now no-op) fetch-pack might be more expensive than a gvfs-prefetch, but I haven't investigated the actual behavior yet.