feat(middleware): mechanism for extending gateway capabilities

[TillaTheHun0]

Background:

Original conversation started on #27.

There is a desire to extend the gateway core functionality, adding new capabilities, for example like those described in ANS-101, ANS-108, and others. However it's also desirable not to have to modify the gateway core in order to do so. Firstly, because that would require gateway runners to modify core code in order to add capabilities, and secondly, it makes the core less stable and secure.

Problem:

We'd like a solution for adding gateway capabilities that is:

1. Self-encapsulated - a capability-implementing module ought to be self-contained, and only have access to do things that core allows it to do
2. Allows for sandboxed experimentation - there ought to be a way to add different capabilities and functionality, without affecting other gateway instances.
3. Good developer experience - gateway runners ought to be able to add capability-implementing modules to their gateway instances seamlessly, ideally without having to write code.

Additional Notes:

A middleware-based solution seems to be a top contender, as it is by nature self-encapsulated.

I proposed a potential solution based on middleware in #27 (comment) that satisfies 1 & 2 above. As far as 3, a natural extension of my solution could use CLI args to trigger dynamically pulling middleware-implementing code from the internet and to bootstrap the gateway with that middleware, on startup. I'd be happy to implement this in a fork, if it's easier to envision that way.

[djwhitt]

One really quick follow up on this today and then I'll drop more thoughts tomorrow:

We've settled on /unstable-extensions as the prefix for extensions under active development. It's intentionally a bit unwieldy because we want users to be fully aware that they're depending on experimental functionality that may change.

Everyone should feel free to use that prefix in their forks even before official extension support is implemented.

[djwhitt]

Dropped some thoughts on the capabilities ANS here: #27 (comment)

I think getting that sorted out should take precedence over defining the extension API since it allows us to coordinate on the set of capabilities even if we're just hacking up forks for a bit.

I also took a look at @TillaTheHun0's fork. I like the idea of middleware extensibility of some sort, but I'm not sure we're ready to decide on an approach yet. Experimentation on forks is very welcome though as long as there's understanding that we may end up standardizing on a slightly different interface.