Remove excessive diagnostics flags, turn on development mode for tests

[farost]

Usage and product changes

We clean the usage of --diagnostics.*** flags used in the test servers because of the recent propagation of a newer version of TypeDB, now supporting the --development-mode.enable flag. As the development mode includes disabling any outer reporting, it is a perfect substitution for this logic.

Implementation

We remove the unnecessary flags everywhere, aiming to cover it by the activated development mode.

• This mode is activated by default for all the TypeDB***Runners [relevant for the Java driver]
• This mode is not activated for vaticle_typedb_artifact fetched by vaticle_typedb_artifact() or built by bazel build @vaticle_typedb_artifact_*platform*//file, so we need to manually add --development-mode.enable=true for all the invocations of these artifacts.

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