Release v19.111.1

Large AppendMany batches no longer slow down by orders of magnitude when the events carry a unique constraint or personal data. A batch like the one in Cratis/Chronicle.Elixir#188 used to outlast a client's call deadline while the kernel still committed it.

Changed

• Unique constraints in a batch append are checked with one read for the whole batch and indexed with one bulk write per thousand changes, instead of two storage round trips per event. A 100-event batch with a [Unique] property now takes about 32 ms instead of 840 ms, and 6000 events take about 0.7 s. (part of #5429)
• Encryption keys for new [PII] subjects are generated ahead of demand, in parallel on every core. A 1000-event batch introducing 100 subjects now takes about 1.2 s instead of 6.9 s. (part of #5429)

Fixed

• A batch of 1000 or more events on an event type with a unique constraint no longer leaves the constraint index pending, which refused the following appends with ConstraintIndexUnavailable. (part of #5429)