Reimagine driver tests for 3.0

[farost]

Usage and product changes

We reimagine driver BDDs in 3.0 to concentrate on the drivers' API testing instead of recovering the server's validations for each client.

The goals are:

• reduce the amount of time spent on driver testing without significant benefits (-> reduce CI costs and mitigate CI configuration);
• make sure that all the drivers implement the required features in a similar fashion;
• make the process of developing and maintaining driver BDDs (both declarations and implementations) faster and lighter.

Implementation

The updated driver BDDs use the updated step declarations from TypeDB 3.0 server but also introduce special steps relevant only to clients to avoid the need to reimplement complex parsing algorithms in different languages.

It's expected that all the drivers maintained by TypeDB cover the following BDD packages:

• connection (mostly for "exotic" cases of a small amount);
• driver (aims to cover all possible API calls that should be implemented for each driver).

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