Add support for pipeline read-aheads and partial reads

[gavv]

We need to rework packet reader interface:

• currently, every reader automatically advances position in stream; instead, it should be controlled manually by the caller -- for Tricky case with Depacketizer and fec::Reader #54 and fec::Reader may illegally drop delayed packets #210;
• depacketizer should be able to access the next packet without advancing current position -- for Add Opus support #51;
• packet readers should be able to report errors when pipeline breaks -- for Forward error codes through pipeline #183;

[gavv]

Depends on #211.

[gavv]

It makes sense to do this together with #183 because both require changes in the same pipeline components.

[gavv]

After much thought, I came to the following interface:

packet::IReader {
    // Shift reading position.
    // After this call, it is guaranteed that packets
    // before @ts are never returned.
    bool shift(timestamp_t ts);

    // Read next packet.
    // Returns a packet that:
    //  - was not returned yet
    //  - is after the reading position set by shift()
    //  - has the minimum timestamp among all such packets
    PacketPtr read();
};

Here are the differences from the current interface:

• the reading position is controlled manually by the caller
• the packet stream produced by read() is no longer monotonic; if a delayed packet arrived that is before the previously returned packet bu still after the reading position, it is okay to return it

Every interface implementer will need to take care of never returning the same packet twice. It would be trivial for some readers (e.g. SortedQueue) but would require some special handling for another (e.g. fec::Reader). We need this because the callers want to handle only newly received packets.

[gavv]

It seems that it will be useful to make a similar change in the audio::IReader interface: separate shift() and read() methods and thereby allow read-aheads without advancing read position. This will allow us to implement PLC as a separate pipeline element without additional latency cost.

PLC element will be placed right after Depacketizer. When Depacketizer returns complete frames, PLC just forwards them. When Depacketizer returns an incomplete frame, PLC may perform (depending on the PLC implementation) a read-ahead request to read the next frame and use it for extrapolation.

Without this change, PLC should be done either part of Depacketizer, or will increase latency, or will not be able to use future frames from extrapolation.

Read-aheads may be also used to pre-fill PulseAudio buffer above the target latency and then, when the read position will be actually shifted, rewrite it with newly rendered samples. Theoretically, this can increase robustness on low latencies.

[gavv]

To extract PLC into a separate element, we would also need to allow partial reads, so that every pipeline element can return fewer samples than requested, and every caller is ready to repeat the call when necessary.

This rather simple change will allow us to ensure that frame flags are relevant to all samples in the frame, by "splitting" the frame if necessary. In particular, Depacketizer may split blank (i.e. set to zero because the corresponding packet was lost) and non-blank parts of the frame into separate frames, and the PLC element will be able to reliably distinguish which samples are blank and which are not.

Without this change, every frame may mix both blank and non-blank samples and it's not possible to say which samples are blank by looking at the frame.