Ignore and do not decrypt received messages when offline, saving resources and increasing performance

[bobslavtriev]

Does NOT DECRYPT the message, saving resources and increasing performance

In this PR, the variable "ignoreOfflineMessages" is included in socket, by default being false. If marked as true, it will ignore all messages received while offline.

[whiskeysockets-bot]

Thanks for your contribution.

The next step is to wait for review and approval to merge it to main repository

The community can help reacting with a thumb up (:thumbsup:) for approval and rocket (:rocket:) for who has tested it.

To test this PR you can run the following command below:

# NPM
npm install @whiskeysockets/baileys@bobslavtriev/Baileys#ignore
# YARN v2
yarn add @whiskeysockets/baileys@bobslavtriev/Baileys#ignore

[PurpShell]

as i mentioned on a similar PR before, I don't really get the premise of these features, but I'll be back later on this PR. I just feel like the PR approach is not optimal somehow.

What if we want to store and decrypt these messages later? The official WA Web would not do this, it will not discard the message like nothing happened. And we can't "simply let the user handle them" as then they'd have to reconstruct all of the message decoding and decryption on their side, not optimal at all. At a time where people are complaining all day at not being able to receive certain messages, offering an option where you don't listen to messages at all in the first place is comical

[PurpShell]

as i mentioned on a similar PR before, I don't really get the premise of these features, but I'll be back later on this PR. I just feel like the PR approach is not optimal somehow.

What if we want to store and decrypt these messages later? The official WA Web would not do this, it will not discard the message like nothing happened. And we can't "simply let the user handle them" as then they'd have to reconstruct all of the message decoding and decryption on their side, not optimal at all. At a time where people are complaining all day at not being able to receive certain messages, offering an option where you don't listen to messages at all in the first place is comical

@bobslavtriev my intention is not to depreciate your work, I think we should encapsulate some of our message decryption schemes in a function users can call later (store the message node then do a sock.reDecryptMessage(node) or something like that)

Currently a very small number of internal functions are exported, this is purposeful to introduce a minimal interface