Expose CafeOutbox to native mobile SDKs

[sanderpick]

Throughout the go lib, methods can add "store requests" which are queued and processed by the CafeOutbox. A store request asks a cafe to pin something. On mobile, these requests should all be handled by the OS via background tasks. This would remove the distinction between "things that can be pinned in go land, and things that must be pinned by the OS".

Additional, if we allowed a "store request" to be associated with a file index from an add (normally a store request is just arbitrary data), we could simplify the proposed flow here: #586, as the "release" could happen automatically when a queue item is done processing. This would greatly reduce the complexity around adding files on mobile because the SDK won't need to keep track of what's pinned / what's not.. it just works it's way through the upload queue, not caring about anything else.

[sanderpick]

Info from duplicate:

• List items
• Delete items

Will need to design what the "item" object is. It should have the hash of the data and the URL where is should be delivered. This will probably look much like a CafeStore object. Or perhaps just return one right before the request is built and sent.

[asutula]

Thinking about this, seems like there's a chance a remote pin will fail for some reason and will eventually be retried. There should be some API to allow the SDK to get the latest metadata about the upload (token, URI, etc) in case that information has changed since last time we go it from the go layer.