spin Move Redis trigger implementation to separate repo

As discussed in this PR #1717, this issue proposes to move the Redis trigger implementation out of the core Spin repo, and to it's own repository, making it a plugin.

The main reason behind this is to make the core Spin repository more lean in it's feature set, and set a precedence for triggers, other than https, to be plugins to the core runtime.

Sep 14 '23 07:09 mikkelhegn

Question: what speaks about moving http triggers out as plugins as well so that all triggers are just plugins? I could certainly see us still wanting to maintain that plugin in this repo and to ship that plugin by default, but it could be nice to not have a model of "all triggers are plugins except http" and instead have a model of "all triggers are plugins and we ship the http one by default".

Sep 14 '23 07:09 rylev

Good question. Regardless of which are in the core repo and not, I think the distributions anyone create can contain any number of plugins. E.g, the Homebrew formula, and install script we provide both install the cloud plugin.

Referring to the release package generated in this repo, I think it makes sense to have something functional, which is why the http trigger was not originally suggested. But we could definitely put that in to that package to address that.

Sep 14 '23 08:09 mikkelhegn