database: improve performance for proposal handling

[countvonzero]

Description

current when a proposal arrives, we do the following steps: 0. decode and initialize

1. db lookup for duplicate proposal
2. register fetch cache with the peer->hashes in the proposal
3. process ballot 3.0 db lookup for duplicate ballot 3.1 check ballot has correct data 3.2 fetch referenced data in ballot (atxs/ballots/blocks) 3.3 check votes are consistent 3.4 check ballot is eligible 3.5 save ballot to db
4. fetch txs in proposal
5. save proposal to db
6. link each tx to the proposal in db

currently on GCP, a proposal can take 800-1200ms, this should be optimized to as little as possible, since proposal propagation and processing time directly affect consensus input to hare.

here is the metrics for time spent on proposal handling step.one can see its dominated by db writes. in the steps described above:

• db lookup: step 1, 3.0, 3.2, 3.3, 4
• db writes: 3.5, 5, 6

[dshulyak]

why do we save proposals to database at all? can they be kept in memory for a couple of layers?

[countvonzero]

why do we save proposals to database at all? can they be kept in memory for a couple of layers?

that's potentially something we can change once we have the all the block generation logic is in place.

[countvonzero]

this measurement is done with GCP default disk. need to measure with 10GB ssd.