## Problem

Lint tests and CI tests were failing.

## Solution

Pin ristretto test runner to Ubuntu 20.04, and bump up linter
dependencies.

Goveralls was failing on community PR's. See
hypermodeinc/badger#1894

Resolves: coverallsapp/github-action#150

Add trivy security scanning workflow to ristretto.

The previous examples were missing package references. Now change to a
complete example. If you want to test this library, just run it directly.

While submitting a documentation PR, CI failed to run my change with the
following flaky error:

    cache_test.go:866:
          Error Trace:  cache_test.go:866
                              cache_test.go:872
          Error:        Should be true
          Test:         TestDropUpdates

This happens because sometimes sleeping for 1 ms is not enough to ensure
the background processing happens. Replace with c.Wait(), which ensures
it waits until everything is processed.

There is a second race, with the full output below. It is caused when
c.Close() is called with the last Set() still in the buffer. This causes
onEvict() to be called for every item. Call c.Wait() before that point
also.

I was able to reproduce these flakes using my "makeflaky" tool:
https://github.com/evanj/hacks#makeflaky-pause-a-process-to-make-tests-flaky
Running it with the following arguments:

makeflaky -goTest . -race -v -run=TestDropUpdates -count=1000 -failfast

* Document the Wait() function
* Clarify that Get() will never return expired items
* Clarify in what circumstances Get() can return (nil, true)

remove typo error

## Problem

I'm interested in getting ristretto to build to the new `wasip1` target,
but it fails due to ristretto's assumption that the program is being
compiled to a unix system where files can be mapped to memory. At this
time, the `x/sys/unix` package does not consider `wasip1` to be a unix
platform, and memory mapping isn't supported either when compiling to
WebAssembly.

```
$ GOOS=wasip1 GOARCH=wasm gotip build
package github.com/dgraph-io/ristretto
	imports github.com/dgraph-io/ristretto/z
	imports golang.org/x/sys/unix: build constraints exclude all Go files in /go/pkg/mod/golang.org/x/[email protected]/unix
```

## Solution

The proposed solution in this PR is to provide stubs implementations of
the memory mapping functions which return `ENOSYS` to indicate that the
functionalities are not available when compiled to `GOOS=wasip1`.

If I'm reading the code correctly, this means that persisting data
structures to a storage medium will not be supported, but the rest of
ristretto should work as expected.

I believe this to be a useful trade-off since many dependents of
ristretto only use the in-memory data structures (e.g.
https://github.com/DataDog/datadog-agent/blob/main/pkg/obfuscate/cache.go,
which is what I'm interested in getting to compile).

A more advanced solution could be to rework the `z.Buffer` internals so
the data structure can work on platforms where mapping files to memory
isn't supported; however, this represents a bigger undertaking, I would
like to first unblock dependencies by allowing the program to compile.

Signed-off-by: Achille Roussel <[email protected]>

glog adds global flags so it is not a good library (adding to an
existing program causes a panic if a flag name conflicts)

## Problem
Cleanup ticker to remove entries for expired keys taking a lot of CPU
cycles around 90% in the case of pod with 1.6 CPU

## Solution
Making the duration of the cleanup ticker configurable so users can
configure it to higher values and can save on CPU cycles.

On our use case we need to rely on expiration timestamps but we realized
that they return zero timestamps. Our assumption is that this is due to
a bug and not by design.

## Problem
When `OnEvict` callback is executed `Item` does not have `Expiration`
field set. Considering it is a public field this needs to be set and
available.

## Solution
Initialize `Expiration` field before calling the `onEvict` callback

* separate ristretto test and coverage workflows

## Problem
I'm currently on Dgraph 21.12 unable to export my data.
Export fails on just two nodes out of 7 with the "Unexpected EOF" error:

```
Dec 14 11:31:51 dm-dgraph-04 dgraph[224355]: I1214 11:31:51.840130  224355 log.go:34] Export [01h26m22s] Scan (12): ~2.1 TiB/2.5 TiB at 177 MiB/sec. Sent: 801.5 GiB at 231 MiB/sec. jemalloc: 7.5 GiB
Dec 14 11:31:55 dm-dgraph-04 dgraph[224355]: W1214 11:31:55.408201  224355 log.go:36] Error while sending: unexpected EOF
```

Skipping rather long investigation of this issue I came to find length
of slice, written to the Buffer during export exceed the size of uint32
(i've decoded varint before Value field in Badger KV struct with RDF's
to get something around 4.5Gb, which is expected for a rather bloated
reverse edge to the one of the most common nodes in my DB. Also count
query returns 72 105 794 connected nodes which is, welp, quite a lot).

Not to mention that working with `int` which is almost always is `int64`
and then casually casting it to `uint32` w/o any checks or warnings is
as bad as it gets.

## Solution
Find any `4` and `Uint32` and carefully replace them with `8` and
`Uint64`. As this happens only in slice-related methods the fix is quite
easy. Locally tests run just fine, but i had to patch the sort one to
accommodate for size changes. Also i did test 21.12-related badger
version and tests run fine too.

## Problem
`cleanupTicker `that is created in `NewCache` is never stopped, which is
why the code below causes a memory leak

```go
for {
	c, _ := NewCache(...)
	c.Close()
}
```

## Solution
Stop `cleanupTicker` in `Close` method