Stratara.ServiceDefaults 4.4.8

• net10.0

  • Destructurama.Attributed (>= 5.3.0)
  • Microsoft.Extensions.Http.Resilience (>= 10.11.0)
  • Microsoft.Extensions.ServiceDiscovery (>= 10.11.0)
  • OpenTelemetry.Exporter.OpenTelemetryProtocol (>= 1.20.1)
  • OpenTelemetry.Extensions.Hosting (>= 1.20.1)
  • OpenTelemetry.Instrumentation.EntityFrameworkCore (>= 1.20.1-beta.1)
  • OpenTelemetry.Instrumentation.Http (>= 1.20.1)
  • OpenTelemetry.Instrumentation.Runtime (>= 1.20.1)
  • RabbitMQ.Client.OpenTelemetry (>= 1.0.0-rc.2)
  • Serilog.Extensions.Hosting (>= 10.0.0)
  • Serilog.Formatting.Compact (>= 3.0.0)
  • Serilog.Settings.Configuration (>= 10.0.1)
  • Serilog.Sinks.Async (>= 2.1.0)
  • Serilog.Sinks.Console (>= 6.1.1)
  • Serilog.Sinks.File (>= 7.0.0)
  • Serilog.Sinks.OpenTelemetry (>= 4.2.0)
  • Stratara.Shared (>= 4.4.8)

A fix for hosts on the Orleans execution model. A store reader that catches up a large backlog and a singleton
work that runs long now answer their keep-alive, so neither leaves reminder errors in the silo's log. A silo that
joins while a singleton work runs long on another silo no longer fails its start. No API change, no schema change
and no migration.

### Fixed

- **A busy store reader or singleton work answers its keep-alive.** On the Orleans execution model, a projection or
 saga reader that caught up a backlog for longer than the runtime's response timeout made its keep-alive tick wait
 behind the catch-up, and Orleans logged `Could not deliver reminder tick` at Error, once per partition and
 keep-alive period. A singleton work whose run outlasted the timeout did the same. Nothing was lost, but a large
 catch-up left dozens of errors on the silo. The keep-alive and the poll now start a catch-up where none is
 running and do not wait for it. A partition is still read by one catch-up at a time, and a commit during a
 catch-up is still applied by it. A singleton work's keep-alive interleaves with its run, and runs still never
 overlap.
- **A silo starts while a singleton work runs long.** A silo that started while a singleton work it registers ran
 longer than the response timeout on another silo waited for that run in its own start. The start then failed
 with a `TimeoutException`. The call a starting silo makes to each singleton work and store reader now
 interleaves, so the start goes on.
- *Operate the Orleans execution model* says that a durable timer whose handler outlasts the response timeout
 still makes Orleans log `Could not deliver reminder tick` for that tick, and that the line says nothing about
 the timer. It also says that, outside a deploy, the line now points to an unreachable store reader or singleton
 work rather than a busy one.