update to idempotent transaction operations

[ryankurte]

with the existing transaction computation applying the same event twice will alter the digest and actual computation, this is likely to cause problems in the event of packet loss, though whether this is a problem remains to be seen when bluetooth / nanox support is available.

to mitigate this we should move to idempotent operations, so that an event sent twice will only be applied once, but return the same value in both cases.

• cache the last digest and only update on new events
• ignore repeated state-change events if we're already in the target state
• use indicies in APDUs to avoid applying events twice to the summary or ring signature computations