Use Keyv type for KeyvMulti.Options stores

[lucasadrianof]

Closes #210.

As described on #210, the remote and local types were incorrectly set to a JS Map (used by Keyv core under the hood). These types should be referencing Keyv instead.

I also fixed the definition unit tests to pass a new Keyv instance for each store to reflect these changes.

A Keyv instance is used by default in the Multi class's constructor in case no override is set (not a Map): https://github.com/microlinkhq/keyvhq/blob/master/packages/multi/src/index.js#L6

[Kikobeats]

Thanks a lot!

[coveralls]

Pull Request Test Coverage Report for Build 10151002379

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.2%) to 96.352%

---

Files with Coverage Reduction	New Missed Lines	%
packages/redis/src/index.js	2	96.3%

Totals
Change from base Build 9203837957:	-0.2%
Covered Lines:	896
Relevant Lines:	916

---

💛 - Coveralls

[Kikobeats]

@lucasadrianof btw what are you building? 😆

[lucasadrianof]

@lucasadrianof btw what are you building? 😆

Nothing too crazy 😆

We have some data that is cached on Redis since it's very frequently read. Since we work with k8s, we can't use a local cache only, but now we have implemented a dual cache (local first + fallback to Redis) to decrease the latency on these reads even more (with a local cache per pod first).