add experimental mmap api

[splitice]

What this PR does / why we need it:

Uses Mmap for compressed chunk data to reduce pressure on linux reclaiming blocks due to golang not returning pages to linux system memory until under high memory pressure. This can cause exteremly high CPU load peaks as all the reclaim work is deferred until the system is under pressure.

10001          9 31.1 29.8 23733032 2429272 ?    Ssl  Mar19 301:49 /usr/bin/loki -config.file=/etc/loki/config/config.yaml -target=ingester -config.expand-env=true

2GB RSS, 23GB virtual. 24GB ram system under high reclaim pressure (process stalled)

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Checklist

• Documentation added
• Tests updated
• Add an entry in the CHANGELOG.md about the changes.

[splitice]

Results from one of our clusters -

With mmap (after ~10 hours):

loki-distributed-ingester-0                        556m         740Mi
loki-distributed-ingester-1                        692m         898Mi
loki-distributed-ingester-2                        273m         725Mi

Without mmap (after ~6 hours)

loki-distributed-ingester-0                        320m         2340Mi
loki-distributed-ingester-1                        237m         2468Mi
loki-distributed-ingester-2                        159m         2120Mi

That's more like it. I don't know exact;y what Golang was doing with its GC and memory management but it's clearly incredibly wasteful. mmap for the compressed blocks is incredible by compsarison.

In it's current form this PR would probably need some changes (perhaps making it configurable?). If anyone from the loki team wants to explore merging this I'm happy to clean it up and make it configurable.

[splitice]

Just over 24-hours:

name                                                      cpu              mem
loki-distributed-ingester-0                        601m         615Mi
loki-distributed-ingester-1                        619m         725Mi
loki-distributed-ingester-2                        361m         581Mi

Bloody brilliant

[stale]

Hi! This issue has been automatically marked as stale because it has not had any
activity in the past 30 days.

We use a stalebot among other tools to help manage the state of issues in this project.
A stalebot can be very useful in closing issues in a number of cases; the most common
is closing issues or PRs where the original reporter has not responded.

Stalebots are also emotionless and cruel and can close issues which are still very relevant.

If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.

We regularly sort for closed issues which have a stale label sorted by thumbs up.

We may also:

• Mark issues as revivable if we think it's a valid issue but isn't something we are likely
  to prioritize in the future (the issue will still remain closed).
• Add a keepalive label to silence the stalebot if the issue is very common/popular/important.

We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task,
our sincere apologies if you find yourself at the mercy of the stalebot.