Release v1.19.0

Stopping or deactivating a background job step now waits for its work to settle instead of only cancelling it, so step work no longer keeps writing after the step or its silo reports that it stopped.

Added

• JobStep.TryInvokeOnActivation lets step work run a callback on its own activation, also while the activation is deactivating. Use it instead of calling the step's own grain reference, for example to save a checkpoint. It returns ActivationCallbackRejected (NoRun, StaleRun, Closed, Cancelled) when the run is gone or the step is stopping. See Jobs.
• JobsOptions.StepStopTimeout (default 10 seconds) bounds how long stopping a step waits for its work, and JobStepError.StopTimedOut reports that the work had not settled in time. The step still reports its stop exactly once when the work settles.

Changed

• Deactivating a job step cancels its work and waits for it within Orleans' deactivation timeout. The step stays recoverable: it writes no final status and reports nothing to the job, and recovery runs it again. (#74)
• A job step reports exactly one outcome per run, after Stop has returned. A stop from the job no longer waits for the step's report, so stopping a job no longer loops back through the step.
• A step's state snapshot is copied with the Orleans DeepCopier<TState>. Silos register it through the serializer; a specification host such as Orleans.TestKit must register it, otherwise the step fails with a message naming the missing registration.
• Steps that still call their own grain reference from their work make deactivation wait for that work, up to Orleans' deactivation timeout. Move those calls to TryInvokeOnActivation.