New: Use database change streams when available

[rodrigok]

Proposed changes

The intent of this PR is to implement our own solution of oplog tailing in replacement of the meteor's one to prevent the internal processing made by meteor. With this change we implemented the possibility to use change streams which is the most efficient way to listen for data changes in database but it's only available from mongodb version 3.6 and when using wiredtiguer storage type.

To make this change we had to:

1. Change all the places where we were still using observers to use our event change from the collections that we've implemented some time ago when we started this movement to move away from the meteor's reactivity solutions.
2. Disable the default presence's and instance's monitor to make the reactivity using the collection's change event mentioned before.
3. Override the meteor's internal mongodb observer to prevent database polling for the internal observers it has.
4. Reimplement the reactivity for the internal meteor users' observer to close connections when the user's token related to that connection was removed.
5. Implement a class to replace the oplog handler that we were listening to fire the change events, now implementing the option to open our own oplog tailing or use change stream when available.

It's possible to configure the behavior with 2 environment variables:

• IGNORE_CHANGE_STREAM=true: which will force the usage of our oplog tailing implementation in place of the change stream.
• USE_NATIVE_OPLOG=true: which will restore the usage of the meteor's internal oplog tailing.

Issue(s)

How to test or reproduce

Screenshots

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Improvement (non-breaking change which improves a current function)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Hotfix (a major bugfix that has to be merged asap)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if applicable)
• I have added necessary documentation (if applicable)

Changelog

Further comments

[sampaiodiego]

• when running a mongodb version not compatible with change streams, if I don't set MONGO_OPLOG_URL I get the following error:

(node:29097) UnhandledPromiseRejectionWarning: Error: URL malformed, cannot be parsed
    at module.exports (/Users/diegosampaio/dev/Rocket.Chat/node_modules/mongodb/lib/url_parser.js:18:21)
    at internal/util.js:297:30
    at new Promise (<anonymous>)
    at internal/util.js:296:12
    at app/models/server/models/_oplogHandle.ts:35:27
    at /Users/diegosampaio/.meteor/packages/promise/.0.11.2.1xavwef.9sbp++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/meteor-promise/fiber_pool.js:43:40

[ankar84]

Looks like breaking changes improve performance a lot.
Good job!