When jemalloc is built with a prefix (the default for the bundled copy
shipped under deps/jemalloc), libc-internal allocations made by glibc
itself - for example from getaddrinfo(3), NSS lookups, pthread internals
or stdio - are served by libc malloc rather than jemalloc and live in
the main arena, growing the program break (the [heap] segment) via
sbrk(2). That memory is invisible to jemalloc and is rarely returned to
the OS automatically: a single live allocation near the top of the heap
prevents glibc from shrinking the program break, so over long uptimes
the [heap] segment can grow to many gigabytes while jemalloc itself
reports a healthy footprint.

This is what is reported in valkey-io#3517: a Valkey 8.1.6 cluster master with
~41 days of uptime where used_memory is ~2.6 GiB but used_memory_rss is
~9.4 GiB. jemalloc shows allocator_frag_ratio = 1.00 and is fully
healthy; /proc/<pid>/smaps shows the [heap] segment grown to ~6.8 GiB,
which exactly accounts for the rss_overhead.

The codebase already had a zlibc_trim() helper that wraps malloc_trim(3)
- the standard glibc primitive for releasing free pages of the main
arena back to the OS - but the helper was only invoked from the Lua
engine after lua_close. MEMORY PURGE only called jemalloc_purge(),
leaving operators on glibc with no built-in way to reclaim the libc
heap and confused by the fact that PURGE did nothing for the symptom
they were observing.

Wire zlibc_trim() into MEMORY PURGE so operators can reclaim the libc
main arena on demand alongside jemalloc dirty pages, update the help
text, and extend the memory doctor diagnostic for high process-RSS
overhead to mention libc-internal allocations as a possible cause on
glibc systems and to point at MEMORY PURGE.

The helper is already a no-op on non-glibc builds, so this change has
no effect on macOS, FreeBSD or musl-based Linux. Verified locally by
running valkey-server under strace -e brk,madvise: MEMORY PURGE now
triggers malloc_trim, which issues madvise(MADV_DONTNEED) on free
chunks and calls brk() to lower the program break, shrinking the
[heap] segment as expected.

Fixes valkey-io#3517

Signed-off-by: Vaibhav Gupta <wweebbssss@gmail.com>

Address review feedback from @zuiderkwast on valkey-io#3640: instead of calling
zlibc_trim() explicitly from the MEMORY PURGE handler, fold it into
jemalloc_purge() itself. That way the libc main arena is also trimmed
automatically when jemalloc_purge() is invoked from other code paths,
which today means the synchronous variants of FLUSHDB and FLUSHALL in
src/db.c.

This also fixes the historical oddity that @zuiderkwast pointed out:
zlibc_trim() was added in a7abc2f to be called from freeLuaScriptsSync(),
but became dead code when valkey-io#2858 moved Lua to a separate module that calls
malloc_trim(3) directly. zlibc_trim() is now reachable again through the
single jemalloc_purge() entry point.

The async paths (lazyfree-lazy-user-flush=yes, EMPTYDB_ASYNC) intentionally
do not call jemalloc_purge() so they continue to skip the libc trim too -
that is correct: malloc_trim(3) briefly locks every glibc arena and we
don't want to do that on the main thread when the user explicitly asked
for an async flush.

Verified locally on Ubuntu 22.04 / glibc 2.35:

  MEMORY PURGE    : [heap] 135168 -> 114688 bytes (-20480)
  FLUSHALL SYNC   : [heap] 135168 -> 114688 bytes (-20480)
  FLUSHDB SYNC    : [heap] 135168 -> 114688 bytes (-20480)
  FLUSHDB (async) : [heap] 135168 -> 135168 bytes (unchanged, as intended)

The behaviour described by the MEMORY PURGE help text and by the memory
doctor's high_proc_rss diagnostic is unchanged; both still mention the
libc main arena and direct users at MEMORY PURGE.

Signed-off-by: Vaibhav Gupta <wweebbssss@gmail.com>

Address the rest of @zuiderkwast's review on valkey-io#3640:

  - Rename jemalloc_purge() to zmallocTrim(). The name "jemalloc_purge"
    no longer fits now that the function also trims the libc main arena,
    and the new name matches the rest of the zmalloc.{c,h} abstraction.
    Updates the three call sites in src/db.c (x2) and src/object.c.

  - Consolidate the two #ifdef branches of the function into a single
    definition with #if defined(USE_JEMALLOC) around just the jemalloc-
    specific code, as sketched in the review. zlibc_trim() runs after
    the ifdef on every build.

  - Trim the comment above zlibc_trim(): keep the part explaining what
    libc-internal allocations are (getaddrinfo, NSS, pthread, stdio,
    modules) and why they end up in the [heap] segment, drop the part
    enumerating which commands call this code.

  - Drop the now-redundant call-site comment in the MEMORY PURGE handler.

Behaviour is unchanged. Locally re-verified MEMORY PURGE, FLUSHALL SYNC
and FLUSHDB SYNC each shrink the [heap] segment by the same amount as
before the rename.

Signed-off-by: Vaibhav Gupta <wweebbssss@gmail.com>

Rename zmallocTrim() to zmalloc_purge() (snake_case, matches the MEMORY PURGE command) across its declaration, definition and the call sites in db.c and object.c. Also shorten the zlibc_trim() comment.

Signed-off-by: Vaibhav Gupta <wweebbssss@gmail.com>