Fixes deadlock caused by blocking Transport::Close()

I must say I am not sure why the block was there. What
the code did, it sent (as a job to another thread [1])
close request to the multiplexer and then blocked till
the multiplexer finished. As said, the code was probably
there to fix something, but it wasn't a correct fix
so if it breaks something I'll deal with it differently.
On first glance I didn't see a problem with removing it
since lifetime of the multiplexer is preserved using
a shared_pointer in the callback to the Multiplexer::Close()
metond, and the method doesn't seem to access anything
in this Transport object.

[1] Since there were only two threads active, we were
in one of them and the other one was blocked by our
mutex, the call to Multiplexer::Close was never
executed.
Bootstrap now returns more kinds of ReturnCodes

Not only kSuccess and kTransportStartFailure
Close multiplexer directly in Transport::Close

Don't send it as an action to another thread.
Renames test: BEH_API_RandomSizeSetup -> FUNC_API_RandomSizeSetup

Because it needs to run longer to avoid false negatives.
Don't start connecting when already being connected

Adds an endpoint set into the Transport structure
for it to know which connections are being established.
This is because two such connection attempts would
interfere and cause undefined behavior. This is a dirty
fix which still has a bug. I.e. when a connection
fails, it doesn't remove the endpoint from the set
of endpoints indicating "connection in progress"
so every further connection attempt will be blocked.
Merge pull request #27 from inetic/MAID-237-transport-close-deadlock

Maid 237 transport close deadlock
Merge branch 'next' into MAID-183-cant-bind-on-bootstrap
Changes log levels from kWarning to kVerbose

Where appropriate
Removes usage of DebugId(...) on few places
Removes state Connection::State::kExactDuplicate

It was never assigned to any variable.
Fix to: Don't start conneting when already being connected

It was not enough to reject connection attempt based only
on the remote endpoint as it is valid to try to concurrently
connect to the same endpoint but different peer node id.
So the rejection now happens based on (peer-node-id, peer-endpoint)
pair.
Try re-binding with different ports when binding in SetupNetwork fails
Merge pull request #28 from inetic/MAID-183-cant-bind-on-bootstrap

Maid 183 cant bind on bootstrap
Merge remote-tracking branch 'upstream/next' into MAID-27-socket-binding-error
Merge pull request #30 from inetic/MAID-27-socket-binding-error

Maid 27 socket binding error