UDPC_atostr(...) uses a uint32_t as an offset into a buffer inside the
UDPC Context such that there can be at most 32 different addr-strings.
The call is thread-safe, up to a point (at most 32 concurrent calls will
return correct strings). The problem was that the offset was not being
reset to 0 and was always being incremented by 40. Should the offset
overflow, the offset into the buffer will be "mis-aligned" such that the
32nd offset into the buffer can possibly overwrite memory past the
buffer's end if the addr string is long enough.
The fix is to use a mutex instead of an atomic uint32_t to lock a
code-block that will always prevent overflow (using modulus operator).
I think the speed-loss is negligable (using a lock instead of an atomic
uint32_t) since it isn't expected for programs using UDPC to use
UDPC_atostr(...) very frequently.
Previously, ids could only be created with an ip address. Now they can
be made with a hostname, which will be looked up by UDPC.
Also fix client still requesting connections even if
accept-new-connections flag is false.
The "data" member variable in UDPC_PacketInfo is now handled as a
pointer to dynamic data, instead of an array with a fixed size. Every
time a UDPC_PacketInfo is received from the context,
UDPC_free_PacketInfo() must be called on it to avoid a memory leak.
Previous implementation had the client send only epoch-time-in-seconds
to be signed by the server. Now the client sends random data and
epoch-time to be signed by the server.
Also added std::mutex for each new std::deque. cSendPkts is left as a
TSLQueue because it needs to support fast removal from the middle of the
data structure (mainly because the queued packets per ConnectionData has
an imposed limit of packets to hold).
