feat(plugins): Plugin workers and strider

[imsnif]

This PR implements plugin workers, allowing plugins to perform background tasks. This PR also includes a draft of a worker implementation for the Strider plugin (searching through files in the background) which will be fleshed out in an upcoming change before the next release.

Worker API

For Rust plugins, in zellij-tile we now provide a ZellijWorker trait. While this API might change a little bit before this feature is released in the next version, this is the general idea:

trait ZellijWorker<'de>: Default + Serialize + Deserialize<'de> {
    fn on_message(&mut self, message: String, payload: String) {}
}

The on_message function will be triggered whenever a message is sent to this worker from the main plugin. Both the message and payload arguments to the function are arbitrary String types, there to allow plugin authors to define their own serializable message types and payloads.

The trait itself requires whatever implements it to also be serializable/deserializable - this is to allow the worker to keep an internal state between runs. The state will be saved on the HD in a temporary folder and used to construct the worker on every run. It is thus advisable to be cognizant of the amount of data placed on the worker state for reasons of performance.

Registering Workers

For Rust plugins, registering workers can be done with the register_worker macro. This macro accepts a struct implementing the above ZellijWorker trait, as well as a namespaced name for the worker with _worker appended to the end. The latter is very important because this is how Zellij recognizes this exported function as a background worker. This namespace is also used to send messages to the worker, see below.

register_worker!(CoolWorker, cool_worker);

Sending messages to workers and back to the main plugin

For Rust plugins, messages can be sent to workers using the post_message_to method:

fn post_message_to(worker_name: &str, message: String, payload: String);

The worker_name argument is used to refer to the namespaced worker we included above. To send a message to the worker we defined above, we would use the cool argument (cool_worker minus the _worker part we use to indicate this is a worker when registering it).

Both message and payload are arbitrary Strings we can use to serialize/deserialize our own private messages. These will be sent as is to the on_message message of the worker.

When a worker wishes to send messages back to the plugin, it can do so using the post_message_to_plugin method:

fn post_message_to_plugin(message: String, payload: String);

This method is similar to post_message_to except it does not accept a worker_name and instead will send the message directly to the plugin. The message will arrive at the plugin's update method with an Event::CustomMessage(message, payload) update event. If you wish to use this functionality, it's important tha the plugin subscribe to these events using the subscribe method, just as it does to all other events.