Handle duplicate blocks in zebra-state

[yaahc]

Motivation

The zebra-state service needs to be able to handle duplicate blocks
idempotently. When we receive a CommitBlock request for a block that has
already been queued we should subscribe to the existing channel for sending the
result of commiting that block. If we receive a block that has already been
succesfully committed to the non-finalized or finalized state we should
immediately respond to the request that the block was committed succesfully.

Solution

This implements changes already outlined by The State
RFC. We check for
successfully committed blocks first, since interacting with the queued blocks
struct at this point just complicates the implimentation. If the block has not
already been committed we then check if the block has already been queued, if
not we handle the block normally (normally here being the bit we already had
implemented).

Documentation Changes

• Update the state RFC to match the ways this fix departs from the design
  • the main thing is that I switched the order of checking for duplicates
• Add newly added functions to the state rfc Decided not to do this because they're minor getters that don't influence the rest of the design and aren't exposed as part of the API
• Document newly added functions inline

Testing

Related Issues

• fixes Panic: hashes must be unique in memory_state #1182
• tracking issue Tracking: State Update RFC Implementation #1049

[teor2345]

This looks really good, I like how neat the implementation is.

I'd like @hdevalence to double-check the channel stuff.

[teor2345]

Edit: This error was due to #1041.

[teor2345]

Edit: This error was due to #1041.

[hdevalence]

Just to back up a second, why do we need to handle duplicate blocks idempotently?

[yaahc]

@hdevalence previous discussion #1101 (comment)

[hdevalence]

Thanks for the pointer!

[hdevalence]

LGTM

[hdevalence]

Clippy failures are unrelated to this PR

[dconnolly]

👍