[Direct Binary Access] Clearly explain causes of missing binaries for getting download URI

OAK-7998 was a good improvement for direct binary access to avoid returning a direct download URI for a binary that does not exist in cloud storage.  However, the implementation is now somewhat ambiguous and does not help the client determine what was wrong.

There are a few cases:

• If direct binary download is not available (e.g. unsupported in the data store implementation or not enabled via configuration) then requesting a direct download URI for a binary returns null.
• If a binary is added via traditional upload (i.e. not via direct binary upload) and then a download URI is requested, it is possible that the binary is still in local cache and not in the cloud yet, and thus a direct download URI is not yet available.  Null is currently returned in this case.  (This is the use case for OAK-7998)
• If a binary is somehow permanently missing from cloud storage, null is returned.  This is a use case that shouldn't happen in normal operation but of course is possible.

Returning null for each case makes it ambiguous to a client and hard to determine why the null URI was returned.

I propose an improvement to direct download generation as follows:

• For the case where the direct binary download feature is not available, continue to return null as is currently being done and as is described in the documentation already.
• For the case where the binary does not exist, the implementation should check to see if the binary is in the data store cache.  This should be possible via the AbstractSharedCachingDataStore.getCache() method.
  • If the binary is in the cache throw an exception along the lines of "BinaryTemporarilyUnavailableException" indicating that the binary is not yet available for direct download but should be soon.
  • If not in the cache, instead throw a different exception along the lines of "BinaryNotFoundException" which is a more severe type of error.

The exceptions can be instances of RepositoryException or subclasses of it, which would not require an API change and therefore would allow this fix to be backported to 1.10.