[health-check] Refactor the config usage

[m-czernek]

What does this PR change?

In this PR, I'm refactoring the config usage in the health check tool such that:

• We use .toml conf file instead of .ini file
• Callers don't have to instantiate the config object to parse properties
• Code doesn't have to pass around config objects to parse properties

NOTE This is a PR into a feature branch, not the main branch.

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

Before you merge

Check How to branch and merge properly!

[agraul]

Thank you for the PR, looks good! We're moving towards https://www.youtube.com/watch?v=1__lNTlj1_w and I like it 😄

I left a few questions and suggestions inline.

[agraul]

Does it make sense to turn access errors into None? This might silence errors caused by bad callers (or bad configs)

[m-czernek]

So you'd prefer we let the caller deal with the error in case it asks for non-existent value? In my mind, when you ask a config for a non-existent prop, the correct behavior is to return a non-existent value (i.e. None).

[agraul]

The caller always needs to deal with the case that it asks for something from the config that can't be found (load_prop(x) returns None).

The question is: do we force the caller to deal with it by raising an exception or are we okay with the caller ignoring that? Both ways are okay, but since we don't have any config validation, it might make sense to not silence lookup errors (e.g. because the config is incomplete and mandatory values are missing) at runtime

[m-czernek]

Ack, makes sense. Fixed - instead of silencing the error, we are now explicit as to the input we wanted to get, where we failed, and the state of config.