Mempool panics if chain desyncs

[Mirko-von-Leipzig]

The block-producer can desync by one block if the store is under duress. An example is if the store takes longer than the gRPC connection timeout of 10s to apply the next block N+1.

The desync occurs because the block-producer assumes the block is cancelled and rolls back block N+1, however the store continues and commits the block. The block-producer is then one block behind the store. This was previously addressed in #1520 which enabled the block-producer to detect this and reset.

What was overlooked is that newly submitted transactions reach out to the store, and therefore get block N+1 as the authenticated block height. This is correct. However, the mempool in the block-producer is only aware of N+1 and we assert that the authentication height cannot exceed the local chain. This causes the submission to panic. Since this is an expected outcome (desync is valid), we should return an internal error instead.

[igamigo]

I hit this a couple times locally in the client after upgrading everything to 0.14. If too many tests are executed at the same time, the machine would slow down (due to all the proving) and the desync would occur. This is also happening in some CI runs where we probably need to reduce concurrent tests even more.