Call complete listeners exclusively when the actor reaches its done status

[Andarist]

related to #4608

this removes the ability to listen for "on stop" but complete was already not called in different scenarios for stopped snapshots:

• like in subscribe here
• or like when starting an actor with a rehydrated stopped snapshot here

So this is currently inconsistent, one way or another, and we should unify it. When it comes to the "on stop" listener - personally, I just don't see a lot of use cases for it. A different modeling approach is always possible and I'd prefer to steer people towards explicit modeling and away from adding implicit ad-hoc logic in listeners like this.

[changeset-bot]

🦋 Changeset detected

Latest commit: 984bdfa

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
xstate	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 984bdfa:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[davidkpiano]

For "on stop", which is still an important "event" to listen for, we can just listen for the snapshot status === 'stopped', right?

[davidkpiano]

I checked, and this PR removed the ability to listen for an actor stopping. I added code to enable this (tests pass locally, not sure why they're failing in CI), can you please review?

[Andarist]

For "on stop", which is still an important "event" to listen for

Why? 😉 Whenever I think about it, I always conclude that I wouldn't ever want to listen to it. subscribe is currently mainly used to notify people about a meaningful change in the underlying data and I think that, more often than not, people wouldn't consider a stopped snapshot something that they need to account for. The stopped snapshot is important for us internally but users should rarely interact with it in their code.

I think it's important to back up the claim of its importance with some real-life use cases oriented on app development and their needs.