Currently, registering a SuspendableActivity will auto-trigger SuspendableActivity.suspend(...) if the activity is registered while the server is suspended, e.g. on server startup.
This requires the registration method to block until the CompletionStage of the suspend completes. Since most activity registration is performed during MSC Service.start(), most consumers do not even realise that this registration is a blocking operation.

I don't fully understand what problem this "auto-suspend on register" logic was meant to solve, but, in my experience, having written several SuspendableActivity implementations, this is usually undesirable (requiring special handling to workaround this unintuitive quirk). It is also a source of confusion, because it is inconsistent with the normal prepare/suspend cadence.

This enhancement proposes to revisit the SuspendableActivityRegistry interface. Currently, this has interface has 2 primary methods:

• registerActivity(SuspendableActivity, SuspendPriority)::void
• unregisterActivity(SuspendableActivity)::void
  ... where registerActivity(...) is really register+auto-suspend+block.

I propose that we replace this cumbersome interface with something like:

• register(SuspendableActivity, SuspendPriority)::SuspendableActivityRegistration

... where register(...) does only what it says, without any of the awkward auto-suspend/blocking.

The returned SuspendableActivityRegistration has two methods:

• getState()::State, can be used by the caller to determine if it needs to "auto-suspend".
• close(), unregisters the activity