Design a simple processing flow for the consumer of incoming

This is a generic issue prior to implementing the actual processing.

Definition of done:

• Have a definition of the algorithm for processing the message, together with the requirements for the interface that needs to be demanded when the consumer registers a callback with the IncomingBox client.

Proposed output: specs for #8884 (closed) (write it in the docstring of whatever classes or functions are needed). Document any interface that's needed.

There's already an example of a proposed flow in #8874 (closed).

Some related notes from the spec:

We need a flow which will call the incoming callback. This issue tries to address this need. Here is how it was described on spec: * To begin a processing round, the client starts by asking a list of the pending messages.

* To avoid potentially costly traversals, the client limits the query to the most recent N blobs flagged as PENDING.

* To avoid downloading very big attachments, client can limit the query on a first pass to all pending blobs  smaller than X Kb.

* After getting the PENDING list, the client MUST start downloading the blobs according to the uuids returned. 

* Download happens as chronological order, from the list. It can also happen concurrently or one by one, as configured.

* The client MUST provide a mechanism so that any trusted application (bitmask mail) can execute a callback for each downloaded message to be processed.