Adding multi-level cache to caching interceptor

[10xSebastian]

This adds the possibility to configure multi-level (local & central) caching for the caching interceptor.

Also:

• Removes old cache configuration keys, e.g. cache_expires_in which have been deprecation warned since years now
• Drops support for ActiveSupport 4 (mainly because only 5.2 introduces RedisCacheStore to ActiveSupport)
• Drops LHC::Caching.logger in favor of simple stdout (puts), mainly because it hasn't been used anywhere

Caching Interceptor

You can also use a central http cache to be used by the LHC::Caching interceptor.

If you configure a local and a central cache, LHC will perform multi-level-caching. LHC will try to retrieve cached information first from the central, in case of a miss from the local cache, while writing back into both.

  LHC::Caching.central = {
    read: 'redis://$PASSWORD@central-http-cache-replica.namespace:6379/0',
    write: 'redis://$PASSWORD@central-http-cache-master.namespace:6379/0'
  }

[10xSebastian]

@christianarevalo

Right now no matter if local cache or central cache, both apply the same provided cache options, as the same caching options apply to a multilevel cache. A multilevel cache is consider 1 cache from a client perspective, just stored on multiple level, following the same options (like expiry).

e.g.

cache: { expires_in: 1.day }

That would make both cache layers expire after 1 day.

For invalidating targeted records, we would still need to implement invalidation services (like for customers etc.). but that's not part of an http client nor interceptor implementation, but rather a dedicated service implementation.