refactor: EmailInbox out of DB Watcher

[ricardogarim]

As per the updates mentioned in PROJ-7, SCA-11 and ADR #74, this pull request focuses on relocating EmailInbox model out of DB Watcher service.

Context

This modification enhances RocketChat's app by allowing it to directly call listeners through the api.broadcast global function, bypassing the need for MongoDB Change Stream data propagation.

This change offers better control over user notifications via Web Sockets, enabling more precise management of use-cases. Instead of notifying every database change, we can now send an api.broadcast call only when necessary, reducing overall network messages. Additionally, this contributes to the future removal of the DB Watcher deployment, optimizing resource utilization.

Proposed changes

Key changes include:

• Conditionally incorporating EmailInbox entity import within DB watchers on application startup based on the dbWatchersDisabled flag.
• Enabling support for the following use cases to directly trigger watch.emailInbox listener event, subject to the dbWatchersDisabled flag.

Updated Use Cases

Use Case	Route/Trigger	Notes
Insert or update email inbox	POST /api/v1/email-inbox
Delete email inbox	DELETE /api/v1/email-inbox/:_id
Reconnect to email inbox on IMAPInterceptor	IMAPInterceptor reconnect > selfDisable functions

Steps to test or reproduce

1. Start RocketChat's application with the DISABLE_DB_WATCHERS environment variable set to true.
2. Perform HTTP requests or simulate use cases listed in the above table.

Further comments

To maintain consistency and avoid potential regressions, event names and signatures have been kept unchanged on both the client and app sides. This decision streamlines efforts and mitigates the risk of unintended consequences.

Additionally, since the EmailInbox model was empty, some new model functions have been created to accommodate specific needs when dealing with database operations.

[dionisio-bot]

Looks like this PR is not ready to merge, because of the following issues:

• This PR is targeting the wrong base branch. It should target 6.10.0, but it targets 6.9.0

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7cb40a2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 56.34%. Comparing base (d06df8a) to head (7cb40a2).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #32501      +/-   ##
===========================================
- Coverage    56.34%   56.34%   -0.01%     
===========================================
  Files         2434     2434              
  Lines        53708    53712       +4     
  Branches     11057    11059       +2     
===========================================
+ Hits         30263    30264       +1     
- Misses       20801    20810       +9     
+ Partials      2644     2638       -6     

Flag	Coverage Δ
e2e	56.02% <ø> (-0.04%)	⬇️
unit	72.24% <0.00%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[debdutdeb]

should findoptions be parameters? generally they should, so people can pass especially whatever subset of projections they need, guess the real question is if that should be done in this PR or not. projections here seem to be specific to the usecases in layers above, and later on somebody else might need to touch these files again to add new ones.

[ricardogarim]

Agree with you, Deb. For this PR, I chose to follow the strict needs of the current use case.

Discussion for the team: should we build methods with "batteries included" from the start, or can we make those changes when they are needed in the future? @sampaiodiego and @MarcosSpessatto, any thoughts?