Approval Voting: Refactor Actions to be less racy and fragile

[rphmeier]

Problem Statement

At the moment, in approval voting, we use a system of Actions for logic to trigger writes to the DB within the smaller functions that perform the actual logic of reading from the DB. The problem is that a function may be called a second time before the actions of the first time have been written, and therefore read outdated data from the DB and produce an incoherent write. More generally, the can arise when calling functions A and B successively without applying the Actions from A before calling B.

In minimized pseudocode:

enum Action {
  WriteThing(Thing),
}

impl Db {
 fn read_thing(&self) -> Thing { .. }
 fn write_thing(&mut self, Thing) { .. }
}

fn update_thing(Thing) -> Thing { .. }
fn apply_actions(&mut Db, Iterator<Action>) { .. }

fn make_actions(db: &Db) -> Vec<Action> {
    let thing = db.read_thing();
    vec![Action::WriteThing(update_thing(thing))]
}

fn bad() {
  let mut db = ..;
  let actions_a = make_actions(&db);
  let actions_b = make_actions(&db); // oops, this is based on outdated state.
  apply_actions(&mut db, actions_a.chain(actions_b));
}

The Backend pattern used in #3277 represents a pretty good fix. Instead of passing around a DbReader and producing actions to be put into a DbWriter, we instead pass around an OverlayedBackend which incrementally will build up a set of operations to be committed at the end. We should do the same here, but also be aware that the approval-db may be going away soon so our backend trait may need to become async so we can fetch the data from a dedicated DB subsystem.

[Lldenaurois]

Beginning work on this refactor now.