Simplified ChunkCache

[overheadhunter]

As suggested during review of #161, using weights on a Caffeine cache it is possible to pin active chunks, avoiding premature eviction.

This simplifies our ChunkCache by purely relying on the atomic operations of said cache and avoids moving chunks between an active and stale collection.

[overheadhunter]

As long as the cache is purely size-constrained (not time-based), I believe that eviction is caused by either of this:

• during ChunkCache.getChunk(long), if the computation results in adding a new chunk to the cache, exceeding the cache size and a stale chunk needs to die
• during ChunkCache.putChunk(long, ByteBuffer) (for the same reason)
• during ChunkCache.invalidateStale(), obviously

Furthermore these places call ChunkSaver.save() explicitly:

• ChunkCache.flush()

I hope this list is truly exhaustive. Since all mentioned methods obtain a lock, it should be impossible during any such call for a different thread to call invalidateStale() (which happens when opening a channel with TRUNCATE_EXISTING).

[overheadhunter]

Since all mentioned methods obtain a lock [...]

I was mistaken: Those methods hold a lock, but eviction runs on a different thread. That is, unless you tell it otherwise:

The executor is delegated to when [...] performing periodic maintenance.

By setting the executor to Runnable::run, we can make sure to run maintenance (i.e. eviction) directly on the same thread, making the eviction behaviour more coherent and comprehensible for our purpose.