Implement LogicManager and Explanation

[dmikhalin]

What is the goal of this PR?

We implement LogicManager, Explanation and corresponding tests.

What are the changes implemented in this PR?

We implemented:

• Rule struct and LogicManager (with BDD steps)
• Explanation, Explainable and Explainables structs and added explainables field to ConceptMap (with integration tests)
• BDD steps for reasoner

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.

[dmitrii-ubskii]

The logic integration tests would benefit from being rewritten in a more clear way. Other than that, could do with some architectural changes.

[dmitrii-ubskii]

The architecture seems solid, but there is still work to do before this can be merged.

[dmitrii-ubskii]

Why the trimming here? Seems to leak the TypeQL internals.

[dmikhalin]

We can almost remove trimming if we construct and parse the whole rule:

    let rule = parse_rule(
        format!(
            "rule {}: when {} then {}",
            answer_identifiers.get("label").unwrap(),
            answer_identifiers.get("when").unwrap().trim_end_matches(";"),
            answer_identifiers.get("then").unwrap(),
        )
        .as_str(),
    )
    .unwrap();
    let RuleDefinition { label, when, then } = rule;
    label.name == answer.label && when == answer.when && then == answer.then

Is it possible to parse it without trimming at all?

[dmitrii-ubskii]

parse_pattern or parse_patterns, depending on whether the then has a trailing semicolon, should be able to parse the then into a conjunction contatining a single variable.

[dmikhalin]

parse_patterns works, trimming has been removed.

[dmitrii-ubskii]

Final polish, I expect, then you can pass it to Josh! I'd suggest running cargo clippy so that it can catch the little things I may have missed.

[flyingsilverfin]

Only 1 major request! Good stuff guys!

[flyingsilverfin]

In the next piece of work can you introduce 'Label' to be sibling of 'ScopedLabel'? Then we can replace these usages of string labels with an actual Label struct.

[dmikhalin]

OK

[dmitrii-ubskii]

Looks good!

[flyingsilverfin]

Looks good to me!! Good job