Fix incorrect behavior in message mode when too small buffer supplied

[ethouris]

The expected behavior in case when a too small buffer was supplied - according to the documentation - is that the message is not extracted and the call to the receiving function ends up with error code SRT_ELARGEMSG.

The current behavior is that if the buffer is too small, then a fragment of a message is extracted, as much as it fits in the buffer, and the rest of the mesage is abandoned. This doesn't make any sense at all, even though this resembles the behavior of UDP when a too small supplied buffer makes the packet completely extracted with only copied the possible fragment of the packet payload, although this is also reported by a flag.

Fragmentary reading should be possible, but only with some special, dedicated API. The default behavior should be as described in the documentation: if the buffer is too small to extract the message, then the operation ends up with error and the message is NOT extracted.

A special API could be also added (maybe a socket option, or using the flags field in SRT_MSGCTRL structure) that could allow extraction of a fragment of a message, while the rest remains in the buffer, and the application can call the receiving function again, to extract the rest of the message, possibly with a need to specify the message number (the same that was extracted by the previous call). If this was called with this flag set, then the returned value could be the total length of the message, and another appropriate flag should be set that says that the buffer has been filled up to the cork and the returned value is greater than its size. This requires some implementation effort to have an appropriate packet flag in the receiver buffer so that it is known how big part of the message was already extracted. The "notch" could be still reused the one used for stream mode.

CURRENTLY this is not a fix - it's only a test case that demonstrates the problem.

PREMATURELY MERGED: #2677 because this PR also modifies the tests for file transmission, so this is to avoid future merge problems.

[ethouris]

I checked the documentation and the mention of SRT_ELARGEMSG under srt_recv is just a copy for srt_send and it doesn't make any sense this way. The mention that too small receiver buffer can also cause this is incorrect.

Possibly the current behavior should be maintained, but some possibility to extract a fragment of a message should be provided. My [FR] proposal:

• Create a flag that will be later passed in the SRT_MSGCTRL::flags field. Say, SRTIO_IN_FULLONLY
• In File mode this means that reading is done only if there's enough data to fill the whole buffer:
  • In non-blocking mode it may mean that reading results in SRT_EASYNCRCV even if read-ready bit is set in epoll
  • In blocking mode it will block until the whole buffer is filled.
  • SRTO_RCVTIMEO is respected and if reached, it simply returns what is still available
  • If the premature returning of fragmentary data happened, SRT_MSGCTRL::flags contain SRTIO_OUT_FRAGMENT set.
• In Message mode this means that the reading is done only if the supplied buffer is large enough
  • Fragmentary reading is never done (in message mode you can't read a message fragment on demand)
  • If this flag is set, a reading ends with error if the buffer is too small and remains completely in the buffer.
  • If this flag is not set, the initial fragment is returned in the buffer, the rest is abandoned, and SRTIO_OUT_FRAGMENT is set in the flags

The minimum set would be the implementation of the SRTIO_OUT_FRAGMENT flag set on output in SRT_MSGCTRL::flags field in case when fragmentary reading has happened. Plus fixing the documentation that isn't exactly accurate.