Fixed error reporting on connect/accept.

[ethouris]

Fixes #1242

[maxsharabayko]

MN_OBJECT is not used in the code (never returned).Something for the future? Do we need to add it then?

[ethouris]

There's another PR that is going to fix problems around the unreported errors from the Mutex/CV creation functions. There are these errors reported. Passing it here might spare too much noise in that PR.

[stevomatthews]

Suggested change

	This error should be reported by the sending function in case when
	with `SRTO_TLPKTDROP` set to true there were packets had to be removed
	from the sender buffer and forgotten because the network is unable
	to live up to the sending rate.
	This error should be reported by the sending function when, with
	`SRTO_TLPKTDROP` set to true, packets to be removed from the
	sender buffer are forgotten because the network is unable
	to support to the sending rate.

[ethouris]

Ok, I'll try to describe the situation. When this error is encountered:

• SRTO_TLPKTDROP flag was set
• the TLPKTDROP on the sender site was triggered (there were found packets in the sender buffer, which's predicted delivery time is already in the past, and they are still not acknowledged - in that case the sender simply drops these packets from the sender buffer and they are no longer eligible for retransmission)

And also the SRT_ENABLE_ECN was turned on at compile time.

In this case the data sending function will return this error, however the data that it has scheduled for sending have been accepted.

Maybe this way:

This error should be reported by the sending function when, with SRTO_TSBPDMODE and SRTO_TLPKTDROP set to true, some packets were dropped at the sender side (see description for SRTO_TLPKTDROP` for details). This doesn't concern the data that were passed for sending by this call (these data are placed at the back side of the sender buffer, while the dropped packets are at the front side of the sender buffer). In other words, the operation done by the sending function is actually successful, just the application might want to slowdown the sending rate to avoid the congestion.

[stevomatthews]

Your last suggestion is much better. Some minor tweaks:

This error should be reported by the sending function when, with SRTO_TSBPDMODE and SRTO_TLPKTDROP set to true, some packets were dropped at the sender side (see the description of SRTO_TLPKTDROP for details). This doesn't concern the data that were passed for sending by the sending function (these data are placed at the back of the sender buffer, while the dropped packets are at the front). In other words, the operation done by the sending function is successful, but the application might want to slow down the sending rate to avoid congestion.

[stevomatthews]

Minor edits.

[stevomatthews]

Approved with minor edits.