Add driver test to check multiple failing schema and write transactions and deadlock/timeouts preventions

[farost]

Usage and product changes

We found that there was a deadlock on the TypeDB server side caused by a failing schema query in a schema transaction not closing the transaction, which led to the schema lock being forever active, not allowing other transactions to be opened.

This PR adds a behaviour test to cover this scenario after the server's fix is merged.

It's uncomfortable to cover this scenario in the connection package to run it for the server itself as we have to manually work with transactions in the test code, which doesn't really test this mechanism. This means that we need a higher level of abstraction, where we only send commands through a connection to the server, where our drivers come to help.

[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

• [x] 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.