Stratara 4.3.1

A correctness release. A projection replay could apply a stream's later fact before its first and
then fail on every attempt, leaving the read models it had emptied empty; the two backfills that
prepare existing history for the Orleans execution model's commit-order readers took the same wrong
order. Beyond that, the setting store no longer needs declared settings, and a setting or permission
vocabulary can be declared in parts.

Upgrading:

• If you replay projections, upgrade. A store in which one save appended several versions of a
  stream can hold sequence numbers that run against those versions, and a replay over it could not
  complete. No entry is rewritten and no migration is needed.
• If you implement IEventStreamRepository yourself, override
  GetManyAfterSequenceInStreamOrderAsync to give your replay the same guarantee; the default keeps
  sequence order.
• If you backfilled a store for a commit-order reader before this release, the Orleans migration
  guide gives the query that tells whether that history holds a stream out of version order, and how
  to repair it.
• A host that declared an empty SettingCatalog as a workaround can drop it. A host that
  registers a catalog through a factory and then calls AddSettingCatalog or AddPermissionCatalog
  now fails at registration instead of replacing that catalog.
• No schema change.

Added

• IEventStreamRepository.GetManyAfterSequenceInStreamOrderAsync: a range of the store in the order a
  replay applies it — each stream's entries in version order, the streams interleaved as their sequence numbers
  interleave them, and the range extended until it no longer ends between two versions of one stream. The default
  implementation returns GetManyAfterSequenceAsync, sequence order, so a repository of your own compiles and
  behaves as before; override the member to give your replay the guarantee.

Fixed

• A projection replay applies each stream in version order. A save does not number its entries in version
  order — EF Core chooses the statement order and the identity column numbers the rows as they arrive — and the
  replay walked the store by sequence number, so it met a stream's later fact before its first. A projection that
  reports a missing preceding fact then failed the batch on every attempt, and because a replay empties the read
  models first, each attempt left the read side empty. On a store where many saves wrote several versions of one
  stream, no replay could complete. The replay now reads through the new repository member; a batch can hold more
  entries than Projections:BatchSize. No entry is rewritten and no migration is needed.
• Both commit-order backfills keep each stream in version order. CommitTransactionIdBackfill could end a
  batch between two versions of one stream, stamping the later one with the earlier transaction.
  PartitionCounterBackfill handed out positions in sequence order, so every save it positioned that the store
  had numbered against its versions was read inverted by the portable reader. Both now extend a batch until it no
  longer ends inside a stream, and the portable backfill positions each stream's entries in version order.
  History backfilled with an earlier version is not revisited, because checkpoints stand on its commit records and
  positions; the Orleans migration guide gives the query that tells whether a store holds such a stream.
• The setting store works without declared settings. AddSettingStore<TContext>() and
  AddSettingStoreFromContextFactory<TContext>() resolved the SettingCatalog inside a factory, so a
  host that registered the store and AddStrataraErasure() but declared no settings built, passed
  ValidateOnBuild and every start-up check, and failed on its first erasure with No service for type
  SettingCatalog has been registered. The store now registers an empty catalog when none is declared:
  the store works, erasure included, and reading any setting through ISettingProvider fails as
  undeclared. The example on AddStrataraErasure was exactly that composition. A host that declared an
  empty catalog as a workaround can drop it.
• A second AddSettingCatalog or AddPermissionCatalog call no longer replaces the first. Each
  call registered a new catalog and the last one won, so a host declaring its vocabulary per module kept
  only the last module's — the others' settings failed as undeclared and their permissions were denied
  without a word. Every call now adds to the one registered catalog, in whichever order it runs relative
  to the setting store. A setting name declared in two parts throws as a duplicate; a redeclared
  permission has no effect and grants to one role accumulate. A catalog registered as a factory cannot be
  added to, and the next call now throws InvalidOperationException saying so instead of replacing it.