Don't trust length specified by ContentProvider for file transfers.

It seems that the length specified by content providers for images
is often not correct. This happens because applications modify the
images later on with meta-data, etc., but don't update the length
field.

This causes Bluetooth OPP transfers to fail, usually with an
IndexOutOfBoundException. The root cause (wrong size in content
provider) of course needs to be fixed, but we can also make
Bluetooth more resilient to these situations.

Since OBEX needs to know the transfer length
up front, the only other way we have of determining the size
of the content is by opening a file descriptor and getting
its length.

Bug: 6857704
Change-Id: Iaf2304b44e9e81ef6e6ac7e0fe3be84ad31a312f