Some PDF shares (and presumably other files) were not shareable due to a failure to convert.
The root of this is that the behavior of
NSItemProvider.loadItemForTypeIdentifier(_:,options:,completionHandler:)
depends on the signature of the completion handler.
The documented signature of the completion handler is: (NSSecureCoding, NSError) -> Void
For example, if you want an NSURL back, it's expected that you'll pass in a
`(NSUrl, NSError)` block, or if you want a Data you'll pass in a `(NSData, NSError)`.
However, that's not possible with Swift strict typing. The type of the block must match.
```
loadItmForTypeIdentifier('myType', nilOptions) { loadedItem, error in
}
```
The type of `loadedItem` is SecureCoding. What we were seeing is that we were
getting returned to us unexpected classes, e.g. private iOS internal classes
like "_NSSandboxedDocument", which indeed do conform to NSSecureCoding.
Instead, we should cut with the grain of the existing API design and request
the exact type of object we want. We do this is ObjC, since this isn't possible in swift,
and provide some bespoke Swift wrappers.
Doing this requires tracking some information about the itemprovider, and
funneling that through the extensionItem -> SignalAttachment process.
1ac44de0d5