Switch from Go native plugins to external binary plugins

[autodidaddict]

Proposed change

Rather than loading dynamic libraries compiled only in Go (which therefore also prevents a plugin-enabled agent from being statically compiled), we should instead adopt the "plugins over stdio" pattern (or a similar variant), loading executable binaries and communicating with them via some transport contract.

Use case

This would allow plugins to be written in other languages than Go, taking advantage of different ecosystems for different workload types. Further, by no longer dynamically loading Go-based plugins, the agent wouldn't have to be statically compiled. Even further further, the agent wouldn't have to have dependencies like V8 (which has strict requirements as well as CGO issues) or WebAssembly. This leaves the agent slim, supporting only process execution for native and plugin-based workloads.

Contribution

No response

[autodidaddict]

I think a design that might make this pretty straightforward to implement might be as follows:

• When we launch a pluggable workload execution provider (after discovery), the agent supplies the NATS URL and the nkey for the internal NATS server to the execution command (identical to how we do today with native workloads)
• execution provider load the appropriate temp file (the cached artifact), the temp file is produced by the agent proper
• the execution provider subscribes (if applicable) to agentint.{vmId}.trigger on the internal connection
• the execution provider is responsible for plugging the workload type into host services wherever appropriate
• execution provider plugin can also listen for undeploy and stop itself

we're already pushing the plugin path down with the machine metadata, which means we can just reuse that.