Propostal: Injection of state into plugin init

[BrynCooke]

Problem

There is a need for some users to inject state into plugin init using more than just yaml. In particular if users are trying to test the router and their plugin relies on an external long lived state then a static are their only option right now.

Statics and tests don't mix well.

Proposal

Add the ability to inject state into plugins and have this participate in the normal lifecycle of the router. This would transmit state from supplied when building Executable to all plugins via PluginInit

Proposed implementation:

StateMachine currently takes a stream of events that supply config, schema, and license.

The proposal is to add two new additional variants to the Event enum:

• CustomState
• NoMoreCustomState

The state machine will be modified to expect at least one CustomState event before starting. The off the shelf router will have a stream of empty custom state followed by no more custom state. This is in line with the other event types.

We have to decide how to transmit the custom state to plugins. Maybe this can be added as a type parameter on Event and propagated to PluginInit. However the developer will have to see what the impact is. If it would change public APIs or the blast radius is huge then downcasting is an option. PluginInit will be extended to have a new method that returns an the custom state.

Executable will be extended to accept CustomStateSource in the same way as the existing sources. and will be documented for public use.