BGP FSM handles changes to passive_tcp_establishment poorly

Passive TCP Establishment for a BGP FSM indicates that it will not attempt to make any outbound connections, instead waiting for inbound connections.

In our implementation:

1. an active (!passive) peer will have its FSM park in the Connect state while it kicks off asynchronous connection attempts when the ConnectRetryTimer fires, and it waits for either inbound or outbound connections to complete.
2. a passive peer will have its FSM park in the Active state while it waits for inbound connections and the ConnectRetryTimer will not run.

While changes to passive_tcp_establishment are visible (via lock!(self.session).passive_tcp_establishment) from the SessionRunner (FSM), there isn't consistent and well-planned logic to ensure the FSM changes its behavior appropriately.

We need some kind of FSM event to notify the SessionRunner it needs to take action. Its handler should react by checking passive_tcp_establishment: stay in Active if false, kick off new outbound connection and transition to Connect if true.

A couple options:

1. Add a new Admin FSM event indicating there's been a change to passive_tcp_establishment
2. Piggyback on ConnectRetryTimer.

If we go with (2) then we need to start running that timer in Active regardless of whether the session is passive.

Regardless of which FSM event we use, we need the handler to check passive_tcp_establishment and transition between Active/Connect appropriately.

Start with the SessionRunner FSM and its handling of the Active and Connect states, then trace ConnectRetryTimer and the passive_tcp_establishment value. Define an FSM event or timer path that observes changes and transitions appropriately; done means passive peers remain in Active while enabled outbound establishment starts a connection and transitions to Connect.