Add Trigger, Rollback, ForceDone autoupdate RPCs

[hugoShaka]

PR 2/4 adding manual rollout control as specified in RFD 184.

This PR adds manual rollout RPCs. Audit events and tctl commands will be added in a followup PR.

[sclevine]

Curious about the motivation for repeatedly retrying on conflict here. Is there something we could watch instead?

(Not blocking, just want to understand the architecture better.)

[espadolini]

The point of "optimistic" locking is that in the happy path where there's no contention, you'll get a single read and a single write. The downside of that is that if there's contention you're gonna have to retry once or twice, and it's a little nicer if we do a couple of retries in the auth where we're closer to the backend rather than having to retry from the client. There's no way to know if a write will succeed or to wait for a write to succeed, the only point at which such a decision can be made is the conditional update.

[sclevine]

I understand the intent behind optimistic locking, but it's unusual to me to see it applied with an arbitrary retry count directly on the backend, vs., e.g., retrying a transaction. I'm assuming we don't have a transaction-like concept given the multitude of backends, and the optimistic lock is our only tool? (Just want to understand this better, not suggesting a change)

[espadolini]

This is, in fact, a transaction (-ish): get some things, make some decisions based on the things, figure out what to write and what are the conditions for the write to go through and not need a retry of the whole transaction, attempt to apply the write. The underlying dynamodb rpc that's used in more complicated situations that involve more than one item (which we surface as (backend.Backend).AtomicWrite) is literally called dynamodb:TransactWriteItems, but for simpler scenarios where the condition is on the revision of the same item that's being written, it's just a conditional write (exposed as (backend.Backend).ConditionalUpdate).

[espadolini]

The point of "optimistic" locking is that in the happy path where there's no contention, you'll get a single read and a single write. The downside of that is that if there's contention you're gonna have to retry once or twice, and it's a little nicer if we do a couple of retries in the auth where we're closer to the backend rather than having to retry from the client. There's no way to know if a write will succeed or to wait for a write to succeed, the only point at which such a decision can be made is the conditional update.