Currently reconnection is a two fold operation:

• First we increment attempt counter
• Then schedule command for reconnect to leverage coalescing system.

This approach produces two individual changes to state which can be misleading when observed from the outside. For instance:

• If the tunnel is currently in .connected state, the first mutation increments attempt counter updating it to 1.
• The observer then receives a .connected state with attempt counter updated to 1.
• The second mutation changes state to .reconnecting with attempt counter set to 1.
• The observer then receives a .reconnecting state with attempt counter set to 1.

Because connected, reconnecting, connecting were handled the same way, the tunnel losing connectivity also starts connection attempt counter at 1 which is suboptimal.

This PR aims to fix the aforementioned issues by introducing ReconnectReason which is passed along with reconnect() command in place of shouldStopTunnelMonitor parameter. tryStart() then is responsible for incrementing the attempt counter following these rules:

• The counter is not incremented If current state is .connected. That's because the tunnel is going to transition to .reconnecting phase and attempt counter should start at zero during the first attempt, then increment with each subsequent attempt.
• The counter is incremented if current state is either .connecting or .reconnecting as normal.

Two tests added to ensure that state transitions for (re)connection attempts happen as expected.

This change is