improvement: implement a subscription notification batcher

[zachdaniel]

This is still a WIP, but by using this strategy we can allow actions to send subscription updates out-of-band.

What remains to be done:

1. This on its own may already be useful, but what we really need to do is now leverage these batches and resolve the loads for lists of notifications. This will massively reduce the amount of queries required to dispatch data, and should significantly raise the scaling properties of these subscriptions.
2. testing & benchmarks

Later improvements

We have batchers, but in the future what we may need is a dynamic amount of them, perhaps partitioned on topic, and load balanced across a cluster potentially. I think we need to start small and test the waters in production use cases with the one orchestrating batcher first, though.

[barnabasJ]

@zachdaniel, should we merge this now? I can create a PR against main this week, removing the unnecessary data we copy.

[zachdaniel]

Yep! Just need to fix conflicts

[barnabasJ]

Yep! Just need to fix conflicts

I can do that, if you want me to.

[zachdaniel]

That would be great, thank you 🙏 you're the best 😍

[barnabasJ]

@zachdaniel I rebased. However, I had to upgrade Ash because there was an error in the alias test. This also led to an igniter update. That now triggered some Igniter Dialyzer warnings.

It looks like those are just deprecation warnings. So I think it should be ok to merge this?

[zachdaniel]

Yep, I'll address those, thanks!