Provide friendly warning when trying to explain an inference while explanations are not enabled

[jamesreprise]

What is the goal of this PR?

We have provided a friendly warning to users when they try to explain an inference while explanations are not enabled.

Closes https://github.com/vaticle/typedb-studio/issues/608

What are the changes implemented in this PR?

We have a new warning message popup, informing users that they must enable explanations under the necessary circumstances.

To do so:

• We've changed the way we access a transaction within GraphArea and GraphBuilder, removing it as a property from GraphArea and making all changes to the graph through GraphBuilder.
• We've added a mechanism to GraphBuilder called transactionSnapshot. This is a way to use the transaction that was used to create the graph, but only if snapshot was enabled at the time the graph was created and the current transactionState.transaction is the same transaction as was used to create the graph.
• We have also changed the naming behind how TransactionState exposes whether a configuration option like 'explain' is enabled for the given transaction or not. Contrary to what one might assume, transactionState.explain.enabled does not mean that explain is enabled (which is what transactionState.explain.value does) - it means that the explain option could be toggled through the UI. We've renamed enabled to canToggle in this context.

[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

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.

[jamesreprise]

Does it make sense for the responsibility of adding vertices to the graph to be split between GraphArea and GraphBuilder? I think it makes more sense to move all functionality regarding the management of graph vertices into GraphBuilder.

My reasoning for this is that once we move the logic for conducting explanations into GraphBuilder, GraphArea has no need for any reference to the transaction at all. This seems cleaner architecturally. If we follow this route, perhaps we can rename GraphBuilder to GraphManager to reflect that it is responsible for the entire life of the graph rather than just its creation.

[alexjpwalker]

The intent was always that GraphBuilder would be solely responsible for constructing the graph structure based on query answers, but then adding in the Explain functionality started to muddy the waters when it came to domains of responsibility.

Yes, it would make sense for all logic that modifies the graph structure to be concentrated into a single class. Not sure about GraphManager as a name though, I think we can come up with something more precise.