refactor: Use MessageDocument directly and use document variants

[dariusc93]

Previously, we would send a Message, which would be encrypted based on the shared for direct messaging or #171 for group messaging due to originally sending this object directly prior to previous refactoring, however this begin to appear redundant as we had additional metadata on MessageDocument that mimics what was stored on Message (eg pinning indication, creation/modified dates, etc), while also storing the encrypted variant on this document. Furthermore, because we will be having additional metadata such as attachments, reactions, etc., on MessageDocument, it only made sense to use it directly instead of storing and Message directly.

What this PR does 📖

• Use MessageDocument directly when sending or referring to the internal message, encrypting the message lines itself rather than Message.
• Store MessageDocument in a reference list instead of a set with each list containing a max of 500 messages before descending into a new list for the next set.
• Implement resolving MessageDocument into Message, allowing us to resolve via bitswap or some other content discovery and fetch protocol when walking its dag.
• Send nonce of an newly edit message so the MessageDocument on the recipient end would contain the same signature when encrypting.
• Add an signature, reactions and attachments as apart of MessageDocument, removing Message::signature (this field was used internally and been planned to have removed)
• Remove redundant and unused spam "filter" (will be replaced in the future with a proper filter and scoring system)
• Use file attachment document for attachments
• Increase file attachment limit from 8 to 32, and remove thumbnail limits

Which issue(s) this PR fixes 🔨

Special notes for reviewers 🗒️

• If peer sends document but disconnects before it is resolved, the message will not resolve and would be skipped. This will change in the future either by matching both conversation documents on connection or some announcement of the message to the intended parties, or in regards to Offline Messaging #45 implementation that will come soon (which the document would be pinned on shuttle, allowing it to be fetched by the intended recipient later).

Additional comments 🎤

• This change allows us to properly and cleanly pin the message on shuttle, and reduce overhead regarding the document itself due to Message being encrypted. This relates to Shard message list and messages in a conversation #125.
• This reduces the size of the document itself, which in turn, would return the size of what is transmitted, and cut back on some of the complexity.
• Reactions may eventually be encrypted in the near future as well on the same document due to the metadata exposure. This will be left as TBD until sometime after raygun: Set a restriction to reactions #415
• While an nonce is to be used once for encrypting and apart of decrypting (for the alg used for this purpose), it is safe to share (as the nonce is shared apart of the encrypted message anyway and is emitted to recipients while being encrypted itself), and is used to make sure the encrypted message matches what the sender (which is the editor) message would be so it would validate. However, this should only be used once. If the current message uses the same nonce that is shared, the message will not be updated and would be rejected on the receiver end (in the future we may track previously used nonce to prevent them from being reused on both senders and receiver side).