Schema commit time validations

[farost]

Usage and product changes

We fix old concept/schema-validation behaviour tests, reformatting them to the new ConceptAPI steps declarations and changing small details in its logic to follow the new validation rules of 3.0.

We also fix a number of new concept/type tests that expected transaction commits; fails; results based on the final versions of commit time validations of the 3.0 server. It is expected that every commit-time validation is now covered by BDD tests.

Additionally, this PR presents new steps for @values, @ranges, @card annotations (with a separate check of get cardinality constraint), and other small things that were forgotten in the past.

Implementation

I'd like to move schema-validation tests to different type files as they have just the same meaning and it's hard to split operation time validations with commit time validations (schema validations in migration). Right now all the old tests are still in the old file for easier review.

For more details, check out the comments in the changed files.

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

Server PR for these tests: https://github.com/vaticle/typedb/pull/7104