chore(docker): jemalloc-accurate local image + contrib/Dockerfile cleanup

[matthewmcneely]

Summary

Add make local-image-jemalloc, a target that builds a jemalloc-enabled
dgraph/dgraph:local image, and clean up contrib/Dockerfile and .dockerignore along
the way.

• New target compiles a jemalloc, CGO, native-Linux binary inside a Linux container, then
  packages it through the same contrib/Dockerfile that CI uses.
• contrib/Dockerfile: drop an unused apt package and a no-op env var, and document the
  real jemalloc tuning knob.
• .dockerignore: stop shipping a ~25GB build context.

Why

On macOS, make local-image cross-compiles with BUILD_TAGS= empty, so it ships a
non-jemalloc binary. Production links jemalloc statically, so the local image is a
poor stand-in for anything memory-related. Cross-compiling jemalloc from macOS to Linux is
the hard part, so this sidesteps it by building natively in a container.

Two smaller issues in contrib/Dockerfile surfaced while I was in there.

Changes

make local-image-jemalloc (+ contrib/Dockerfile.build)

Multi-stage builder. Compiles the binary in a golang Linux container (jemalloc built
from source and statically linked, CGO on, default BUILD_TAGS=jemalloc), exports it via
BuildKit, then packages it through contrib/Dockerfile. Defaults to the host arch so the
jemalloc compile runs natively; set BUILD_PLATFORM=linux/amd64 for amd64-CI parity
(qemu-emulated).

contrib/Dockerfile cleanup

• Drop libjemalloc-dev. The binary links jemalloc statically
  (/usr/local/lib/libjemalloc.a via the ristretto z package cgo directive), so no
  libjemalloc.so loads at runtime. Confirmed with readelf -d and grep on the built
  image, so the runtime package was dead weight.
• Remove GODEBUG=madvdontneed=1. It has been the Go runtime default since Go 1.16, and
  it only ever governed the Go heap, never jemalloc's off-heap arenas where the large
  allocations live. It was a no-op here.
• Document JE_MALLOC_CONF as the tuning knob (prefixed, because jemalloc is built
  --with-jemalloc-prefix=je_, so plain MALLOC_CONF is ignored), plus the
  narenas/percpu_arena caveat for CPU-limited containers and a link to the jemalloc
  docs.

.dockerignore

Exclude dgraphtest/datafiles (~24GB of LDBC/test fixtures) and cached binaries. Build
context drops from ~25GB to under 1GB. linux/ stays included so contrib/Dockerfile's
ADD linux still works. This also fixes the existing local-image target and any
docker build . in the repo, which were all shipping the full 25GB.

Testing

Built the image and verified in a container:

• dgraph version reports jemalloc enabled : true
• statically linked (no libjemalloc.so in readelf -d)
• baked malloc_conf present, libjemalloc-dev absent from the image
• version string stamped correctly

Note

The default make local-image on macOS stays non-jemalloc on purpose (fast iteration, no
per-change container build). jemalloc is opt-in through the new target. Everyday CI on
Linux already builds jemalloc, so this mainly helps macOS developers doing memory-related
work.