instruct DCO about expected residual data over the socket

[ordex]

When passing the socket to kernelspace, userspace may had already started reading a new (but not complete!) packet.
This means that now DCO will receive data which is not the beginning of a new packet, but rather the end of a previous one, that is partly buffered in userspace.

This goes against the current assumption made bvy DCO, that is "I expect new packets from the beginning".

To fix this scenario, userspace could pass a "residual length" parameter along with the socket telling DCO how many bytes should directly be passed to userspace before assuming that a new packet will begin.

This change should happen in the new-peer command.

[ordex]

Note: this is quite unlikely to reproduce and so far we never received any report. But it is something that can theoretically may happen.

[ordex]

As of now userspace won't make this happen, because it checks if there is any residual and if so, it just bails out.
However we will likely implement this feature to improve flexibility and avoid corner cases.