godzie44 authored 11 months ago and Yaroslav Dynnikov committed 11 months ago

Introduce a plugin system for picodata cluster.
Plugin system contains:
- `picoplugin` crate with plugin interfaces.
This crate exposes plugin interfaces for user implementation and API
that used by picodata to interact with plugin as with a code from dynamic library.
- Support for plugin work cycle in picodata instance work cycle.
Picodata instance interacts with running plugin by `PluginManager`
component.
Typically, plugins react to events that occur in instance or whole cluster.
- New lua API with plugin CRUD actions.
    - pico.create_plugin - load a new plugin into picodata cluster
    - pico.remove_plugin - remove plugin from picodata cluster
    - pico.update_plugin_config - update plugin service configuration

The code inside process_topology_request_async has become too complex
therefore TopologyRequest has lost its utility

refactor: rename UpdateInstanceRequest -> update_instance::Request, UpdateInstanceResponse -> update_instance::Response

Use direct structure names instead of aliases for better IDE code surfing

Rewrite it from scratch to satisfy tests and to represent governor
logics in general.

Cases covered:
- when someone goes offline
- whenever vshard gets reconfigured

Tarantool remote requests are handled in a IProto thread, and
on_shutdown triggers are handled in the TX thread.

During shutdown we send a request to the leader, which introduces a race
condition in case we are the leader. If iproto thread shuts down before
the request is sent, it will never be handled.

The fix is simple: in case we are the leader during shutdown, don't send
the request, instead handle the request directly in the TX thread.