[Feature] Add Slipstream Plugin Support

[dgrkotsonis]

Summary

Wires the Slipstream plugin system (implemented currently on a feature branch in snarkVM) into snarkOS so that node operators can load one or more streaming plugins at startup and manage them at runtime via authenticated REST endpoints. Validator and Client nodes both support plugins; Prover nodes do not (they do not finalize blocks).

This PR tracks snarkVM's stream_plugin_testing branch and adds the corresponding plumbing in snarkOS on a new add_slipstream_plugin_support branch. (TODO: Update and unpin from specific commit once snarkVM changes merged in)

---

Changes

Cargo / feature wiring

• All Slipstream functionality is gated behind --features slipstream-plugins. Nodes compiled without the feature are unaffected. The flag propagates through the workspace: snarkos → snarkos-cli → snarkos-node → snarkos-node-rest → snarkvm.
• Cargo.toml — Added snarkvm-slipstream-plugin-manager as a new workspace dependency
• node/Cargo.toml — Added snarkvm-slipstream-plugin-manager as an optional dep, propagate new slipstream-plugins feature flag to enable it alongside the corresponding snarkvm features.
• node/rest/Cargo.toml — Same optional dep + feature wiring.
• cli/Cargo.toml — Added slipstream-plugins features forwarding to snarkos-node.

CLI

• cli/src/commands/start.rs — Added --slipstream-config PATH flag (repeatable; feature-gated). Empty slice is passed when the feature is disabled so the call site is always uniform.

Node layer

• node/src/node.rs — Threaded slipstream_configs: &[PathBuf] through new_validator and new_client.
• node/src/validator/mod.rs / node/src/client/mod.rs — After Ledger::load, if plugin configs are provided, a SlipstreamPluginManager is initialized and injected into the FinalizeStore

REST API

• node/rest/src/lib.rs — Registered three slipstream routes behind the existing JWT auth middleware (feature-gated). Added DELETE to CORS allowed methods.
• node/rest/src/routes.rs — Implemented three handlers:

Method	Path	Description
GET	/{network}/slipstream/plugins	List loaded plugins
POST	/{network}/slipstream/plugins	Load a plugin from a config file
DELETE	/{network}/slipstream/plugins/{name}	Unload a plugin by name

PUT (reload) is not yet implemented and is left as a TODO.

Error mapping: PluginNotLoaded → 404, PluginAlreadyLoaded → 422, all others → 500.

Tests / docs

• node/tests/common/node.rs — Updated client() and validator() test helpers to pass &[] for the new parameter.
• docs/slipstream_plugins.md — New operator guide covering: what Slipstream is, plugin ABI and build instructions, JSON5 config format, startup flags, full REST API reference, and curl examples.

---

Usage

Build with plugin support

cargo build --features history -p snarkos

Start a client node with two plugins

snarkos start --client \
--slipstream-config ~/.aleo/plugins/postgres/plugin.json5 \
--slipstream-config ~/.aleo/plugins/metrics/plugin.json5

List loaded plugins

curl -H "Authorization: Bearer $JWT" \
http://localhost:3030/mainnet/slipstream/plugins

Load a new plugin at runtime

curl -X POST -H "Authorization: Bearer $JWT" \
-H "Content-Type: application/json" \
-d '{"config_file":"/path/to/plugin.json5"}' \
http://localhost:3030/mainnet/slipstream/plugins

Delete/Unload a new plugin at runtime

curl -X DELETE -H "Authorization: Bearer $JWT" \
http://localhost:3030/mainnet/slipstream/plugins/{plugin_name}

---

Notes

• All plugin-related code is gated on #[cfg(feature = "slipstream-plugins")], so builds without these features are unaffected.
• Plugin manager lock errors (poisoned RwLock) surface as 500 errors; plugin call errors during finalize are logged as warnings and never propagated to the node.

[dgrkotsonis]

Is there a better place to put this file rather than creating this new docs dir? (Unlike snarkVM there isn't a specific plugins crate to put this in)