Revert transport state to avoid having an embedded observable in one of the variant

[BillCarsonFr]

Proposal to revert that change b0eb566 and keep only static variant of state instead of having one of the observable variant beeing him self another observable.

 | { state: "FailedToStart"; error: Error; transport: LivekitTransport }
  | {
      state: "ConnectedToLkRoom";
      connectionState$: Observable<ConnectionState>;
      transport: LivekitTransport;
    }

I think it makes it easier to use. I added back the test that was deleted
2c66e11
image.png

If this proposal is not accepted, then at least the deleted test should be added back using the new API

[BillCarsonFr]

maybe we could have a switch map from a new startLifecycle observable if you prefer

[robintown]

I don't agree that this is necessarily easier to use. As the diff shows it's basically a matter of map versus switchMap, and meanwhile what was a clean declarative specification with almost nothing to test becomes imperative + with poorer locality of behavior.

There are also some things that become easier to do when state is not flattened in this way, such as maping with ideal performance when you don't care about the ConnectionState, or accumulating a state that resets whenever you're outside the ConnectedToLkRoom phase.

This is not high-temperature feedback and you're welcome to merge this if you still like it better, but I just wanted to give context as to why, more generally, I think we shouldn't shy away from dynamic values that contain other dynamic values when they're also a valid way of modelling a problem.

[robintown]

This subscribe call would need a .pipe(this.scope.bind()) to avoid risk of leaking, for the record