Performance issue when there are many links

Final Solution:

A radio button will be provided with two options: Synchronous and Asynchronous.

Each option will include a description explaining its functionality. Please note that the asynchronous option relies on queues and cron jobs.

When the Synchronous option is selected, the administrator can define the number of links that should be processed asynchronously.

It is not necessary to inform the editor when this occurs.

Until this issue is resolved I think there should also be a warning on the module homepage that "Recalculate dependencies using queue" should be used in production.

I have implemented the solution on comment #4; these are the changes in MR:

Processing Modes:
- Replaced process_mesh_using_queue checkbox with two radio button options:
- Asynchronous (default): All dependencies queued for background processing
- Synchronous: Smart processing based on dependency count
- Added synchronous_limit field (default: 25) for synchronous mode threshold

Processing Logic:
- Entities with dependencies ≤ limit: Process immediately
- Entities with dependencies > limit: Queue to prevent timeouts
- New countEntityLinks() method counts dependencies without full processing

Configuration Migration:
- Update hook 10012 migrates old configuration to new structure
- Removes deprecated process_mesh_using_queue setting

Tests
- Added kernel tests for processing mode logic
- Added functional tests for settings form

Moving to needs review!

I have fixed too a bug found in the countEntityLinks() method where self-referencing links were being included in the dependency count. The getTargetLinks() method was counting the current entity's own canonical URL as a dependency link. This has been fixed by filtering out the entity's own URL from the target links array before counting. This ensures that entities don't incorrectly inflate their dependency count with self-references, providing more accurate threshold calculations for the synchronous/asynchronous processing logic.

Hello Juanjo,

Great contribution once again—it's very valuable.

Just a comment regarding how many times the getFullEntityDom method can be executed for the same entity. First, it is run in the countEntityLinks method. If the count does not exceed the limit, the entity is processed again in the setTargetsInSourceFromEntityRender method.

It might be possible to implement a way to keep the DOM in memory to avoid regenerating it just a few lines later. A simple approach could be to use a static variable inside the getFullEntityDom method. Then, during the second execution, rendering the entity would not be necessary.

Or perhaps this optimization is not needed if the resource impact is minimal. What do you think?