Persistent Cache Implementation using RocksDB

[darkmatter18]

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

Description

The Pull request implements Persistent Cache with RocksDB.

The implementation uses an in-memory cache mechanism using Caffeine and a Write-through persistent cache based on RocksDB.

Fixes

1. When there are too many mutation events (more than cache.max.capacity) being "processed" in a very short period of time, this can occur on high loads on the in-memory cache, causing eviction and duplication in the data topic.
2. When the connector restarts (manual restart operations or crashes) in between processing events arising from a single mutation, the data is wiped out from the in-memory cache but stays in the persistent cache.

What's added/changed

• A new class named PersistentCache.java which implements the MutationCache.java interface, having the persistent cache implementation.
• A new configuration named cache.persistent.directory to enable the persistent cache and set the cache directory at the same time.
• Renamed the old MutationCache.java to InMemory.java, which has a non-persistent in-memory cache implementation.

Checklist:

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.

[darkmatter18]

Closing this PR as #198 has the same implementation.