Change how implementations of PeriodicMemoryChecker are selected

[czentgr]

PR #24922 made a PeriodicMemoryChecker to be part of PrestoServer.
The LinuxMemoryChecker is an implementation that can be enabled by adding a build flag (macro) to select it PRESTO_MEMORY_CHECKER_TYPE:

presto/presto-native-execution/presto_cpp/main/CMakeLists.txt

Line 144 in b2919fa

if(PRESTO_MEMORY_CHECKER_TYPE)

In the PR it was discussed that perhaps this isn't the best way going forward and a discussion with the OSS community needs to occur. See #24922 (comment)

Meta also has its own implementation of the PeriodicMemoryChecker used internally: #24922 (comment)

We use the LinuxMemoryChecker in our own builds but are open to changes in how it can be selected. The main reason for doing it the way it is done is that users of PrestoC++ have a choice at build time which code of MemoryChecker to use. A user would drop in their own C++ file and add to the CMakeLists.txt and as a result select to build that file into the executable. The usage would then be configured through the config.properties.

@spershin @tangjiangling @majetideepak @minhancao

[czentgr]

@spershin @tangjiangling We can discuss this in the next native worker group meeting.

[spershin]

@czentgr
The macro is not really needed here.

What we do internally at Meta is simply have a class that inherits from facebook::presto::PrestoServer and then implements (overrides really as it is virtual) void createPeriodicMemoryChecker() and fills the PrestoServer::memoryChecker_ variable inside.

That's it.

The default PrestoServer::createPeriodicMemoryChecker() implementation currently calls
memoryChecker_ = createMemoryChecker();
which implementation is in turn it tied to this precompiled definition macro thingy PRESTO_MEMORY_CHECKER_TYPE.

This is done not to break current use cases.

Ideally, it would be good for any implementation of presto_cpp to have that override if we need a special tracker and drop the macro altogether.

Let me know if this made the issue more clear.