Call malloc_trim() regularly to improve deallocation behavior

[sfan5]

adds a workaround which fixes #14645
as I suggested in my comment

To do

This PR is Ready for Review.

How to test

1. test scenario from the forum post

[siliconsniffer]

How can I try this out?
Edit:

• checked out to this commit
• compiled it
• server with mineclonia seems to work fine, ram usage goes down and up as it should

Do you need more info? Video?

[sfan5]

Do you need more info? Video?

No that's fine, thanks for testing.

[Desour]

• How expensive is malloc_trim, for the thread calling it, and for other threads using the heap while it's trimming?
• If someone uses a different allocator with LD_PRELOAD, we should probably not call malloc_trim. Maybe add a build option and/or an env variable to turn this off.

[sfan5]

How expensive is malloc_trim, for the thread calling it, and for other threads using the heap while it's trimming?

I have no idea. I think this unknown is mitigated by just not calling malloc_trim too often.
FWIW it was good enough for mruby: mruby/mruby#5069

If someone uses a different allocator with LD_PRELOAD, we should probably not call malloc_trim. Maybe add a build option and/or an env variable to turn this off.

I don't agree.
In the worst case we're just calling glibc to trim an empty heap. In the best case the allocator has overriden this to do something else useful (or a no-op).