Check config key

[yhmtsai]

This PR adds the check to verify the keys in config are allowed by predefined keys set.
typo in config is quite easy in the file because we do not have auto-complete for that
It avoids typo or misusage of parameters from user such that the configuring solver is not what users expect without notice.

it use config_check_decorator(config, additional_keys) now, it provide the get function like usual config and will check any disallowed key in the end.

[MarcelKoch]

Suggestion: use the pnode to keep track of which keys of a map were accessed. If not all keys were accessed, then there are some invalid keys.
The pnode will also keep track of what is the set of allowed keys, since the parser function will test for all valid keys.

[upsj]

Implementation example:
Replace

if (auto& obj = config.get("max_iters"))

by

std::set<std::string> allowed_keys;
auto get_config_value = [](const char* key) {
    allowed_keys.insert(key);
    return config.get(key);
};
// ...
if (auto& obj = get_config_value("max_iters"))

The main goal is to specify every key name string only once, so we avoid accidental typos.

[yhmtsai]

It merge the allowed keys preparation with trying getting nodes now

[upsj]

Looks mostly good, but I would like to eliminate some potential for bugs, and simplify the diffs

[upsj]

LGTM! I only would like to find some better names.

[upsj]

decorator is not a particularly descriptive name, what if we named it config and renamed the parameter to something like config_node?

[yhmtsai]

we already used config for the object to hold property tree, so I would like to have the name easy to distinguish the behavior.
config_checker checker is okay to me or config_tracker tracker?

[upsj]

typename config_check_decorator and variable name config_check?

[yhmtsai]

looks good to me

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.8% Coverage on New Code
5.3% Duplication on New Code

See analysis details on SonarQube Cloud