Potential CSndUList array overflow

[maxsharabayko]

This is a rework of #724 (closes #724).
The default size of CSndUList was 4096 elements. The list is a heap of SRT sockets, that are to be processed in the sender's thread.
It is very unlikely to have mare than 4096 SRT connections, that is why checking if there is a place to insert a new socket is not required most of the time. However, if there is no place, then there will be an overflow and out-of-border operations.
This PR fixes this.

• CSndUList::update(...) increases list size if required.
• Reduced default size of the CSndUList from 4096 to 512.
• CSndUList::remove_(...) now uses std::swap
• CSndUList::insert_norealloc_(...) now uses std::swap

[ethouris]

That's not the best approach to handle the memory allocation problems. You simply do nothing and behave as if allocation succeeded. If this is a proper and predicted memory allocation error handling, please at least leave a comment that describes how it is handled. Trouble is, things like "double the size" for allocation - unlike usual critical memory resource allocation - should be predicted for temporary resource problems. For example, a socket that fails to be added to this list should be somehow postponed or even closed, if there's no other choice.

[maxsharabayko]

CSndBuffer throws CUDTException(MJ_SYSTEMRES, MN_MEMORY, 0). Probably the same has to be done here.

[ethouris]

Well, I thought it can't be done, but indeed - the only functions from public API of this class is remove and update, and update is the only call that can cause this problem is from CUDT::sendfile and CUDT::sendmsg2.

Maybe it would be even better idea to move the insert function to a private section? If not even remove... When I did so for testing, the code still compiles.

[maxsharabayko]

insert is private now. Renamed to insert_ and insert_norealloc_ (according with the naming of the class) and removed the mutex lock.

[rndi]

Maybe remove spaces around '*'? The syntax is confusing enough, spaces make it look even more like multiplication. This is, obviously, an opinion, feel free to ignore if your opinion differs.

[ethouris]

A kinda standard in C++ is that there is no space between type name and * for pointer types (or even more precisely, to glue the asterisk rather to preceding type name than to a following symbol name - which isn't exactly the case here though). Spaces around * as a multiplication operator is another matter.

[maxsharabayko]

Applied CLang format from #772 to this line of code.
Changed
temp = new CSNode * [m_iArrayLength * 2];
to
temp = new CSNode *[2 * m_iArrayLength];

[FedericoCeratto]

This vulnerability is tracked in CVE-2019-15784
@ethouris: Do you plan to make a new release soon? Thanks