There are currently 3 cases where we need vote extensions but don't have them, and if we don't have them we panic:

1. A fresh node joining an existing network that block sync's and then switches over to consensus
2. An existing node that goes down and comes back again at a later stage
3. The whole network goes down and comes back up again simultaneously

See this E2E test run for examples of 1 and 2.

The core reason for this is that we currently don't store precommits' extensions anywhere. When we switch over from block sync to consensus we call CommitToVoteSet which effectively simulates the precommits. This worked for ABCI, but won't for ABCI++, since we don't store the vote extensions anywhere at present, causing panics in nodes attempting to switch from block sync to consensus.

Some possible solutions we've considered thus far:

1. Create a new type, ExtendedCommit, which contains a commit and its associated vote extensions and extension signatures. Upon each commit, store the last_seen_commit (of type ExtendedCommit, with vote extensions and their signatures) in the block store.
2. Either:
   1. Extend the StatusResponse for the block sync protocol to also supply the node's last_seen_commit, including vote extensions.
   2. Devise a workaround such that, if a node needs to propose as it switches from block sync to consensus (for which it needs vote extensions and their signatures), signal internally to the node that they've just switched over such that they produce an invalid proposal. This proposal will be rejected by the network and the next proposer will be chosen.