Action node that executes a separate BTree

Nodes should follow multi-Raft (actix-raft?) algorithm to reflect:

• changes to BT execution state;
• changes to Blackboards.

• repeat should fail on first failure and pass success after n successes;
• retry should pass success on first success or fail after n retries;

Architecture layers should be separated and the interaction between them possible to define from the user level. The layers should include:

• Connectors: various 'observers' on external systems, e.g. file system connector, email connector, GSuite connector;
• Events: this layer should handle mapping between Connectors and Data Services such as Global Records Service and Blackboards Service;
• Data: this should be directly accessible for Behavior Trees / Agents or any other automation;
• Automation: BTs and any other automation abstractions should live here and use only the Data layer for receiving data.

Endpoints Service is an example of a Connector.

All of the layers should use the same Value space (buttercup-values).

Mapping between the layers should be configurable by the end user, i.e. which events are put into which Record tables and which BTs will listen on those or use those in their processing.

After stabilization of the API test coverage should be > 80%

Connectors should produce events which in turn should be consumed by:

• records service;
• local / global blackboard services;
• analytics service.

Endpoints service should emit event as one of the Connectors. Mapping of events to internal data processors should be easy to configure, there should be a shorthand for linking Endpoint services to a family of local blackboards.

Parts of the code are old and use matches extensively making it less readable.

Replace match use with ? and From<T> for error enums.

Ractive nodes should be linked to variables updates. This issue depends on: #10

Record is just a set of named Values.
This is just a BT adapter layer over SQL-like databases.

Materialize.io looks promising as you can subscribe to queries which allows for reactive conditions over query results.

https://crates.io/crates/rust_decimal

seems to have much more support than num_rational and num

buttercup-agents test fails because of the Arbiter vs. actix_rt runtime mismatch

Nodes should have Arc<> to child nodes instead owning them, so that external services can ask reactive nodes to reevaluate conditions and stop child futures if needed.

Events Service mapping should be configurable as to which Records it populates - if any - and also which family of blackboards it should touch on receiving an event.

Diesel + postgres

Node should take a Transformation definition and perform it saving the result in appropriate variables

ValueHolder should use Arc so that it's possible to copy reference to a value

Root nodes should be able to execute the tree:

• one-off: once and then off;
• until-stopped: despite fails it will repeat;
• to-first-fail: will repeat unless there's a failure or error returned;
• reactive-condition: until some condition is true.

Decorator nodes for transforming states from the child nodes:

• reverse, i.e. success -> failure, failure -> success;
• ignore failure, i.e. failure -> success;
• error as failure, i.e. error -> failure;
• always success.

The tests write to the hard drive and as those currently pass locally there's a problem with running them in Github Actions.

Endpoint service that is configurable with different extraction strategies that will push values to other services and will allow for transformations of provided data.

GQL api that can be composed over multiple crates with async-graphql.