Concept Type BDDs for all the types, edges, its annotations and ordering

[farost]

Usage and product changes

We refactor already existing BDDs for concept/type package, adding new base cases of type manipulations and refactoring already existing cases for better scalability in the future.

We add tests for all the annotations from 3.0 and basic lists (of roles and of owns) manipulations for:

• entity type;
• relation type;
• attribute type + relates (roles);
• owns;
• plays.

The ultimate goal of this PR is to have decent coverage for schema and refactor the concept/type tests so this format could be reused in concept/thing later on, additionally being available for small additions on the schema level.

Moreover, all the files now tend to have structure for easier test cases search:

• common steps
• common lists steps (if applicable)
• annotations common
• special cases for specific annotations
• annotations combinations
• -- you can insert your new feature here --

Implementation

I won't put many additional comments inside the steps declarations, here is the whole process of additions and refactoring and my logic behind it:

Setup:

• I created new files: owns.feature and plays.feature.
• I moved all entitytype and relationtype tests that check owns behavior to owns.feature and tests that check plays behavior to plays.feature.
• relates behavior (roles on the concept level) remains a part of the attributetype file.

Owns:

• I added base cases of the possibility of owning something from a root type for all the possible combinations.
• I refactored the moved from entitytype and relationtype files tests, putting most of them under a Scenario Outline with Examples of entities and relations (I add these entities and relations to the Background step so they always exist for Examples substitutions). Some of them are left separated so as not to spam entitytype/relationtype X attribute-valuetype permutations. I also added some more declaration basic and inheritance cases.
• I duplicated everything mentioned above for lists: owns smth[] as it's easier to add special cases for lists later, and Examples for Scenario Outlines would cause too much trouble for this case.
• I covered all the possible annotations: base cases of declaration (with fails), inheritance, redeclarations, etc.
• I covered special cases for specific annotations with all the possible attribute value types (that's why they are separate). Additionally, I added negative cases for unsupported annotations and positive-negative cases with annotation combinations!

Plays: I copied the base of owns tests and followed the same ideas. The main differences here:

• I only added some tests for playing a role from a list of roles (me sub relation, relates smth[]; ... plays me:smth), no tests for lists of plays as we don't support it yet.
• The only compatible annotation for plays is @card, so there are much fewer cases for annotations
• I spent less time on refactoring existing tests from old files

Entity type and Relation type: Followed a similar approach as for plays, haven't refactored old tests much, but tried to cover annotations decently. Relation types also received additional special tests for relates (roles) and lists of relates.

Attribute type: Closer to owns for easier changes and scalability regarding annotations, but active in using the old tests for simple cases.

Addons:

• I've tried to put steps declarations to a similar form of type(name) get smth(name) get smthelse contains:, etc. Now for the schema level, but I'll be able to propagate this refactoring everywhere once we approve it.
• There are many TODOs that require our revisiting later / while fixing the code based on these tests / right now as a part of the review. I'll highlight the main ones by my comments so we can address them here. All the other TODOs are much easier to be addressed while working with code.

[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.

[farost]

I added some new TODOs for me to address. I'll add a new comment here when the PR is ready for a new review cycle. Otherwise, you can check my answers to the previous comments and check the new commits!

[farost]

Had a huge update over all the tests in this PR based on the implemented logic on the server side!

There are too many details to mention, all the valuable discussions and decisions were highlighted in our Discord.

There is still a number of TODOs for future work on schema validation, not implemented features and small stuff, but it looks like we can merge it in this form and address it later.

Currently, all the tests in type pass for my branch with validations and fixes: https://github.com/vaticle/typedb/pull/7094

[farost]

Honestly, I feel like there are some of the tests written for some of edges (owns/relates/plays) that are not explicitly covered by other edges, but there is too many things in the scope at the moment. I tried to cover everything thoroughly and can guarantee 95% of the cases to be covered by the tests, the rest I'm sure we'll check through test coverage checks later