Benchmark a complex scenario [WIP]

[nachocodoner]

Solves: #5

After resolving the performance limitation in 3.1.1, as reported here, we now aim to set up a more complex reactive stress scenario. This involves adding more observers, running multiple unblocked subscriptions across additional collections, and querying with dynamic parameters.

This level of stress testing will better reflect real-world conditions. It will help us verify whether the optimizations introduced in 3.1.1 (async queue and compression defaults) perform as expected under more complex scenarios, or if new regressions surface, requiring further adjustments.

New behaviors introduced in this PR:

• Register users using accounts instead of relying on sessions
• Task creation with status cycling (pending → in-progress → done), with all tasks visible across all connected clients to maximize reactive observer stress
• Checklist items scoped by taskId, expanded by default so every client maintains active subscriptions and observers for all tasks
• Comments and subcomments scoped by taskId and commentId, using https://github.com/Meteor-Community-Packages/meteor-publish-composite for nested reactive joins, also expanded by default across all clients
• Reactive summary aggregation across all users' tasks using https://github.com/robfallows/tunguska-reactive-aggregate, grouping task counts by status
• New Playwright test script and Artillery stress config under /complex route, with configurable parameters (TASK_COUNT, CHECKLIST_ITEMS, COMMENTS_PER_TASK, REPLIES_PER_COMMENT)

All publications are unscoped, every connected client receives every other client's mutations across all three collections (tasks, checklists, comments), matching the approach used in the basic scenario. This ensures realistic reactive load under concurrent Artillery sessions.

This is an opportunity to develop a dynamic performance suite designed to test community package libraries as well. It allows configurable parameters for reactive approaches used in benchmark tests, along with additional adjustments in the future.

Usage of redis-oplog, could also be interesting. But I left for additional efforts after initial complex setup.

[nachocodoner]

This PR will be a good candidate to test more advanced and full-coverage reactivity for change stream vs polling or oplog analysis.

We need to create the new UI on a separate page at localhost:3000/complex and implement its behaviors using new collections, subscriptions, and reactive third-party libraries. A new test script will be needed to use the new page. The scenario mentioned in the description of the PR would be good to have it.