[ZIP 227] Finalization should occur immediately, not at the next block boundary

[daira]

Existing implementations in practice consider transactions within a block to act on the global state sequentially, and they perform consensus checks accordingly. (Pointed out by @str4d.)

[daira]

This is a similar state-access-ordering issue to #957, and this comment from there applies:

This [ambiguity] is a consequence of the use of imperative statements like "reduce the value" or "increase the value" [in consensus rules]. I don't want to claim these are strictly never used in existing consensus rules, but it is undesirable to use them because of ambiguities like that above [between issuance and the check for burn validity]. It is far preferable to refer explicitly to indexed states, i.e. to define notation for the global state before and after the transaction. Then a consensus rule that performs an "update" can be rephrased as imposing a relation between the before-state and after-state, which resolves a lot of potential ambiguities (in particular, conflicting requirements automatically do the right thing which is to reject the transaction).

[vivek-arte]

We made the remaining changes to resolve this in QED-it#81. This has been merged into our main working branch, and is thus now included in #960.