Two improvement ideas

Hi first, let me say thank you for this project. I'm interested in implementing Simplex myself, and just going through your README clarified a lot of things that I was unclear about.

While studying Simplex, and especially thinking about membership changes I got two ideas, and since you're the only people I'm aware of that are implementing it, let me just describe them. Feel free to ignore them if you have no time for it.

#### Delayed membership changes

After reading (very appreciated again) your description of membership changes, I am wondering if it isn't simpler to just schedule membership changes with a delay.

So e.g. if a consensus member change was notarized in the Block in a round R, it is scheduled to go in a affect in round `R + DELAY`. This gives protocol plenty of time to finalize everything and ensure all peers have the save view of the membership, irrespective of their view when it was finalized.

I was thinking `N * X` rounds, mostly to make it proportional to the number of members, assuming that the failure is more likely when number of members is large, and every `N` rounds, every member had a fair change to be the leader. But an arbitrary number/formula would probably do, picked depending on how conservative the protocol wants to be vs how willing it is to wait for changes to take an affect.

Keeping track of schedule of consensus membership changes seems just much simpler than juggling epochs and parallel consensus state, etc. While in applications I can think of membership change being delayed seems like almost unnoticeable implementation detail.

While thinking about how likely it is that peers wouldn't be able to finalize blocks before a DELAY of rounds, another idea occurred to me.

#### Increase round time relative to the number of unfinalized rounds

While, assuming reasonable connectivity, the protocol is pretty much guaranteed to finalize quickly, what if the connectivity is bad or someone is even intentionally messing with it? Or there's more malicious peers than `f`?

Unless I'm missing something, if the consensus can't finalize, nodes are just rapidly accumulating blocks they can't finalize and using up memory.

Seems to me that the timeout time is actually somewhat arbitrary, and does not need to be constant between peers.

If in a round, peer notices that the number of blocks pending finalization is larger than some threshold (like N?) it can just increase the timeout. If more peers are experiencing finalization issues, this will slow down producing new rounds, additionally preventing "Delayed membership changes" from running over `DELAY`. Since apparently the consensus is not working anyway (either due to more peers being malicious than `f`, or active attack , or maybe even a bug), slowing down rounds seems like a robust defensive mechanism.