RFC: Effect Routing

[charypar]

This is an RFC for a replacement for effect middleware, and a proof of concept test demonstrating how it would work. Not every detail is covered, but hopefully enough for feedback.

The more feedback the better!

[charypar]

@StuartHarris this hopefully matches our conversation a while back. It's turned out reasonably nice, other than having to deal with the annoying reference cycle between the core/router and the core-side effect handlers.

I've managed to keep the serialized FFI "lane" broadly the same, but an argument could be made that we should have one typed resolver per effect even in the serialized case and fully avoid the possibility of resolving effect A with a value for effect B.

[StuartHarris]

Let's do it!! ;-)

[charypar]

@StuartHarris I had a go at solving both of those problems by reifying the idea of lanes in code (I call them routes now). This both hides both the registry implementations (bridge one and new one), so we can change and optimise them how we like, and makes it impossible to resolve effects without running the effect pump.

Each route looks a bit like a core in its API, but it can be anything we find useful. The user is responsible for defining the route set, but we create it and give it the router weak ref. The dispatch function then gets the complete, ready to use route set, and the FFI can access it through the router.