Stratara.Outbox.RabbitMQ 4.3.1

• net10.0

  • Microsoft.Extensions.Configuration.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.DependencyInjection (>= 10.0.11)
  • Microsoft.Extensions.Hosting.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.Logging.Abstractions (>= 10.0.11)
  • Microsoft.Extensions.Options.ConfigurationExtensions (>= 10.0.11)
  • RabbitMQ.Client (>= 7.2.2)
  • StackExchange.Redis (>= 3.1.31)
  • Stratara.Abstractions (>= 4.3.1)
  • Stratara.Contracts (>= 4.3.1)
  • Stratara.Mediator (>= 4.3.1)
  • Stratara.Sessions (>= 4.3.1)
  • Stratara.Shared (>= 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.