👌 feat(message:deduplication) implementing the feature #33

[vladshub]

A way to manage message de-duplication in grabbit.

Implementation details:

• Each instance would set its own policy, it can be the default - None, reject duplicates - Reject and ack duplicates - Ack
• Each service can set a duration to store each message in the duplicates table
• Once a message is received from grabbit we check if the message-id is in our table
• If it's in the table we invoke the policy
• If it's not in the table we add the message, using our internal transaction, to be stored in the db
• Once the processing is complete we and the internal tx is committed the message-id is also committed into the DB.
• In the background we have an additional scheduler running which deletes messages that are older then what is set in the policy (currently hardcoded every minute to reduce the number of messages deleted in iteration to a minute)

This PR closes issue #33

[coveralls]

Coverage decreased (-0.2%) to 76.13% when pulling c2d8b8c5ecf9c89113b786fbabe92fd7daf93ed7 on feat-33 into 60007d8cbc0915ead1e718dce3aeb26aa4c0ffc3 on master.

[vladshub]

@vladshub wouldn't it be easier to de-dup when publishing from the transactional outbox rather than when consuming the message?

@rhinof we can but if we do that we can't guarantee that a service will receive only one since issues with the connection to rabbitmq might create additional duplications and also the time a message is in-flight might provide for additional duplications.

[vladshub]

@rhinof & @adiweiss can you please re-review?