Fix transaction identifier collision

[Qnbie]

It's a fix for the #146 issue. If the two transaction ID is the same, it throws an error and rebuilds the connection.

[LanderV-Vintecc]

Shouldn't the response be ignored if the transaction id is different, instead of throwing an exception? Throwing will result in no data being read and thus data loss.

[Qnbie]

The data loss will also occur, if we just ignore the response. With an exception at least we know about that and also reconnection could happen.

[LanderV-Vintecc]

It would require a larger change, but you could keep in memory the responses for the different transaction id's, waiting until the response for "your" id is received, and then continue. Out of order responses are a part of the protocol, so this does not indicate a "bad" connection, so a reconnect is not necessary.

[mRy0]

I ran into the same problem today.
There should be an implementation with a dictionary of the transactionID and a TaskCompletionSource and asynchronous waiting for the response.

This should handle multiple requests fine.

Also a configurable semaphoreSlim to limit the max concurrency for some embedded devices