feature(spin): Support for custom Spin triggers

[Sven Pfennig]

Spin has a plugin system that allows Spin apps to be triggered by user-defined events. To add a trigger to the spin-shim it needs to be added to the source code e.g. #192

Since it is not desirable to add all possible triggers to the shim, it would be nice to use the existing plugin system to load the plugins at runtime. Trigger plugins are standalone binary CLI programs that take the path of a locked spin application as a parameter.

I see two options:

Option 1: Mount Spin plugins folder from Host

With this approach, the plugins can be conveniently managed on the host using the spin cli tool, and only the mount needs to be added to the shim. However, it is a piece of "dark magic" for the user, and the plugins still need to be distributed across all nodes of a Kubernetes cluster (in the case of K8s).

Option 2: Make the shim aware of plugins and fetch them during container startup

This option fetches the plugin during container creation, what makes startup a bit slower but does not need the plugins being installed on the node.

Thoughts

• In the end, a trigger plugin is just another thing which has a lifecycle that needs to be managed. I see this as outside the scope of the shim.
• Locating and executing a trigger can be done similar to the trigger_command_for_resolved_app_source function in the spin CLI https://github.com/fermyon/spin/blob/main/src/commands/up.rs#L152-L153
• Executing binaries is a potential attack vector we should be aware of. (maybe this feature can be made optional)

[Jiaxiao Zhou]

I can see this as a very useful addition to the spin shim. Thanks for brining this up @0xE282B0 !

I am personally preferring the second approach where the spin shim is aware of the plugins because this seems more ops friendly.