[4373] Allow backend definition of ExpandAll tool in the explorer

[gdaniel]

Bug: #4373

Pull request template

General purpose

What is the main goal of this pull request?

• Bug fixes
• New features
• Documentation
• Cleanup
• Tests
• Build / releng

Project management

• Has the pull request been added to the relevant project and milestone? (Only if you know that your work is part of a specific iteration such as the current one)
• Have the priority: and pr: labels been added to the pull request? (In case of doubt, start with the labels priority: low and pr: to review later)
• Have the relevant issues been added to the pull request?
• Have the relevant labels been added to the issues? (area:, difficulty:, type:)
• Have the relevant issues been added to the same project and milestone as the pull request?
• Has the CHANGELOG.adoc been updated to reference the relevant issues?
• Have the relevant API breaks been described in the CHANGELOG.adoc? (Including changes in the GraphQL API)
• In case of a change with a visual impact, are there any screenshots in the CHANGELOG.adoc? For example in doc/screenshots/2022.5.0-my-new-feature.png

Architectural decision records (ADR)

• Does the title of the commit contributing the ADR start with [doc]?
• Are the ADRs mentioned in the relevant section of the CHANGELOG.adoc?

Dependencies

• Are the new / upgraded dependencies mentioned in the relevant section of the CHANGELOG.adoc?
• Are the new dependencies justified in the CHANGELOG.adoc?

Frontend

This section is not relevant if your contribution does not come with changes to the frontend.

General purpose

• Is the code properly tested? (Plain old JavaScript tests for business code and tests based on React Testing Library for the components)

Typing

We need to improve the typing of our code, as such, we require every contribution to come with proper TypeScript typing for both changes contributing new files and those modifying existing files.
Please ensure that the following statements are true for each file created or modified (this may require you to improve code outside of your contribution).

• Variables have a proper type
• Functions’ arguments have a proper type
• Functions’ return type are specified
• Hooks are properly typed:
  • useMutation<DATA_TYPE, VARIABLE_TYPE>(…)
  • useQuery<DATA_TYPE, VARIABLE_TYPE>(…)
  • useSubscription<DATA_TYPE, VARIABLE_TYPE>(…)
  • useMachine<CONTEXT_TYPE, EVENTS_TYPE>(…)
  • useState<STATE_TYPE>(…)
• All components have a proper typing for their props
• No useless optional chaining with ?. (if the GraphQL API specifies that a field cannot be null, do not treat it has potentially null for example)
• Nullable values have a proper type (for example let diagram: Diagram | null = null;)

Backend

This section is not relevant if your contribution does not come with changes to the backend.

General purpose

• Are all the event handlers tested?
• Are the event processor tested?
• Is the business code (services) tested?
• Are diagram layout changes tested?

Architecture

• Are data structure classes properly separated from behavioral classes?
• Are all the relevant fields final?
• Is any data structure mutable? If so, please write a comment indicating why
• Are behavioral classes either stateless or side effect free?

Review

How to test this PR?

This PR shouldn't change the current behavior of Sirius Web.
To test that expand all is working as before, open a studio and:

• Ensure that the ExpandAll tool is available and works as expected in the default explorer

• Ensure that the ExpandAll tool is available and works as expected in the domain explorer

• Ensure that the ExpandAll tool is available and works as expected in a domain tree representation

• Ensure that the ExpandAll button is available and works as expected in the model browser
  Open a papaya project and:

• Ensure that the ExpandAll button is available and works as expected in the selection widget

• Has the Kiwi TCMS test suite been updated with tests for this contribution?

[gdaniel]

I defined a new extension point for these components because treeItem#contextMenuEntry corresponds to pure frontend components: their precondition is evaluated in the frontend, and is the only thing that matters to display them or not.
On the other hand, treeItem#backendContextMenuEntry corresponds to frontend components that can be received from the backend (they may be in the received payload, or not). As a result, they are added to the menu only if they are part of the payload.
There is maybe a better way to do that, but my main idea was to limit the changes to ExpandAll, and not change other contributions using the treeItem#contextMenuEntry extension point. This implementation also ensures that the behavior of existing contributions using the treeItem#contextMenuEntry remains the same after this PR.

[gdaniel]

I created a hook for the "default expand all behavior", because this feature is not only needed by the ExpandAll tool in the contextual menu, but also by the model browser and selection widget.
The new Sirius Web ExpandAll contribution uses this hook, but downstream applications can override it while keeping the existing behavior of the model browser and reference widget.

[gdaniel]

I tried to fix the formatting but couldn't make it work. I guess my configuration is different from the one of the previous committer. Let me know if this is not acceptable and I'll manually update it.

[gdaniel]

I reused the icon for the SingleClickTreeItemContextMenuEntry. Let me know if I should use something else.

[gdaniel]

The main idea of the PR is to extract the ExpandAll context menu entry as a Sirius Web contribution. This implies that the expand all logic should be removed from sirius-components-trees. Trees now provide a single function to update the expanded items they contain.

On the backend side, the View DSL now contains a CustomTreeItemContextMenuEntry with a contributionId that tells the frontend which component to put in the context menu. These entries are transformed into SingleClickTreeItemContextMenuEntry DTOs with dedicated IDs to minimize the impact on the frontend.

Sirius Web has been updated to define an ExpandAll contribution that matches the previous behavior. This contribution is used in all the places where ExpandAll was previously available.

[gdaniel]

Coverage of sirius-components-view-tree and sirius-components-view-tree-edit is lower than expected, but the methods that can be covered in the new classes are covered by the existing tests.

New class CustomTreeItemContextMenuEntryImpl

Existing class FetchTreEItemContextMenuEntryImpl

I am not sure what to do to improve coverage on these modules, generated code is not well covered, so any addition will decrease the overall coverage of the module.