Refactor console for 3.0

[farost]

Usage and product changes

We refactor console to support the updated typedb of 3.0-alpha.

Implementation

Non-existing features are deleted. Non-implemented features are commented out (cloud, user management, options).

The new output looks like this:

> database create its-my-pr
Database 'its-my-pr' created
> transaction its-my-pr schema
its-my-pr::schema> define
                   attribute name, value string;
                   entity person, owns name;

Success
its-my-pr::schema> commit
Transaction changes committed
> transaction its-my-pr write
its-my-pr::write> insert $x isa person, has name "John"; $y isa person, has name "Alice";

Finished validation and compilation...
Finished writes. Streaming answers...

   ---------
    $x | iid 0x1e00000000000000000000 isa person
    $y | iid 0x1e00000000000000000001 isa person
   ---------

Finished. Total answers: 1
its-my-pr::write> commit
Transaction changes committed
> transaction its-my-pr read
its-my-pr::read> match $x has name $a;

Finished validation and compilation...
Streaming answers...

   ---------
    $a | Alice isa name
    $x | iid 0x1e00000000000000000001 isa person
   ---------
    $a | John isa name
    $x | iid 0x1e00000000000000000000 isa person
   ---------

Finished. Total answers: 2

The release pipeline should be the same. However, we may need to update the dependencies on typedb artifacts later in the following smaller prs.

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

[flyingsilverfin]

Can we bring back the $ before the variables on the left side Also can we make sure there's a newline after the committed message (your example has it sometimes):

its-my-pr::schema> commit
Transaction changes committed
> transaction its-my-pr write

And maybe we can use Finished validation and compilation... instead of Completed since then we have Finished throughout?

[farost]

@flyingsilverfin fixed formatting in the description, I've inserted some excessive newlines while copying the text. Added $ and two more -- in the table dashes for symmetry.