Proposal 0022: re-keying repairs both groups, whatever wrote the key

[delchev]

Adds proposals/0022-rekey-repairs-both-groups.md.

1.5 is already normative for aggregates: both tuples are repaired when a grouping key moves, and "the previous keys cannot be recovered after the write, so a conforming generator observes them before it". Two gaps sit next to that sentence:

1. rollups are not held to it. Their section says nothing about re-parenting, and proposal 0021 leaves the vacated parent a MAY. A sum roll-up over a re-parented line is therefore specified to correct the parent that received it and to go on counting it in the parent it left. Nothing about the construct justifies the difference — a roll-up is an aggregate over one key.
2. The repair is attached to one writer, not to the write. Observing the previous key "before the write" is naturally implemented on the path that carries a whole record (a form submit). A generator that also emits targeted writers — a process step's field setter, a lookup that resolves a relation, a task form persisting what it edited — has other ways to move exactly that column, and those writers deliberately raise no ordinary change event. The move a process makes, on records nobody re-opens by hand, is the one that silently skips the repair.

The proposal adds no syntax. It states the repair as a property of the write: when a grouping column changes, both the group the record left and the group it joined are recomputed, however the column was written — and the repair must reach the derived-total handlers without turning into a second change event for the record.

Found while fixing the same two gaps in a conforming generator: eclipse-dirigible/dirigible#6819