GH-1: Implement mydb_dedicated_server

[alexeykopytov]

Add a new system variable mydb_dedicated_server with the functionality described in the Github issue.

The variable is ON by default, which creates some challenges for MTR testing:

• the amount of resources allocated by mysqld with that variable set to ON is incompatible with the typical use case of MTR running multiple jobs and servers in parallel;

• values of other variables that are auto-tuned by mydb_dedicated_server may depend on hardware resoures and OS limits

Changing a certain variable from its default value for MTR runs is not as simple as it may seem. Test suites or individual tests may override whatever was set up by MTR. I tried a few changes to MTR code or its default .cnf files, and none of them was reliable enough. I ended up introducing a new environment variable `MTR_TEST_MODE``.

When set to any value, it makes certain variables change their default values to the ones that make more sense in the MTR testing context. For now, the only affected variable is mydb_dedicated_server, but more variables may be added later.

Closes GH-1.

[ihanick]

This change will be problematic for MyDB installed in containers (docker/kubernetes) if the server has huge amount of RAM, but just few GB is granted for MyDB.

Can we consider cgroups memory limit check in my_physical_memory?

    std::ifstream file("/sys/fs/cgroup/memory.max");
    if (!file.is_open()) {
        file.open("/sys/fs/cgroup/memory/memory.limit_in_bytes");
        if (!file.is_open()) {
            return 0;
        }
    }
    std::string line;
    std::getline(file, line);
    
    if (line == "max") {
        return 0;
    }

[alexeykopytov]

This change will be problematic for MyDB installed in containers (docker/kubernetes) if the server has huge amount of RAM, but just few GB is granted for MyDB.

Can we consider cgroups memory limit check in my_physical_memory?

    std::ifstream file("/sys/fs/cgroup/memory.max");
    if (!file.is_open()) {
        file.open("/sys/fs/cgroup/memory/memory.limit_in_bytes");
        if (!file.is_open()) {
            return 0;
        }
    }
    std::string line;
    std::getline(file, line);
    
    if (line == "max") {
        return 0;
    }

Right, but this is technically an innodb_dedicated_server issue, which was addressed upstream in 9.3.0:

InnoDB now supports container-aware resource allocation, allowing it to adhere to the restrictions imposed by the container. The default values of InnoDB configurations are now calculated based on the logical CPUs and physical memory allocated by the container, rather than relying on system-wide resources.

For now, we can consider containers a "non-dedicated" server. Backporting container-aware allocation from 9.3.0 looks reasonable.