Added timeout reason. Updated correctly reject reason on timeout

[ethouris]

Fixes #1164

[maxsharabayko]

It does not look right to mix connection rejection reason and connection timeout.
Although I see it is easier to implement.
How would you estimate the corectness and effortt to do the same via srt_getlasterror(..)?

[ethouris]

It's not possible to be done via srt_getlasterror because it remembers it in a thread-specific storage, not for a socket-specific storage.

You'd need to add a new field that will remember the operation status in the socket. The call to APIError will have to store this value somehow in both places so that it can be later retrieved by a new function, kinda srt_getlasterror_in(socket_id). So should function that perform the connection in the background.

For implementation in the groups I don't even have an idea - especially that the same id can be simultaneously used for sending data and connecting a new link, which is also done in the background, so theoretically an error on the group for connecting would have to be stored differently than any other error, or we'd have to make a very specialized function that would be used exclusively to get the connection errors in order to maintain interchangeability between sockets and groups in the API.

[maxsharabayko]

The problem this PR is addressing is getting the reason for a non-blocking connection to fail.

1. A non-blocking srt_connect(..) returns immediately. It reports only errors due to incorrectly specified parameters.

2. Call srt_epoll_wait(..) to get notified of the connection state.
   If there was a connection timeout, the error is reported in read and write FDs.

Calling srt_getlasterror(nullptr) returns a thread-local error, not an error for the socket.

This PR reuses srt_getrejectreason(socket_id) to get connection timeout error as well.

[maxsharabayko]

Requested changes

• Update description of srt_getrejectreason(..)

[stevomatthews]

Minor edits

[maxsharabayko]

The documentation should also provide a guideline for when to call srt_getrejectionreason(..) in a non-blocking mode.
It does this for a blocking mode only as of now.
srt_epoll_wait(..) errors if you waited for a connection. Then get reject reason.
What would be the workflow for rejection reason if epoll waits both for conection events, and reading events, if this workflow is the correct one. 🤔