Implement module to get configuration values from the database

[mcalmer]

What does this PR change?

We started to move configuration values from rhn.conf into the database rhnConfiguration table.
As we need now some of the moved values in python code, we need a function which get us these
from the DB.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes

• DONE

Test coverage

• No tests: add explanation

• DONE

Links

Addition to: #9423

• DONE

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!

[Serp1co]

lgtm

[m-czernek]

A few comments while just passing by.

[m-czernek]

So we want:

• For specific values, we want specific type defined in the inner dict
• Otherwise, we want an int,
• Unless it's a float.
• But default return from a DB is string (right?), so if it is neither an int or a float, it'll be a string anyways
• Finally, if it is an empty string, return None

Is that accurate? (I'm asking because this inner method seems confusing to me, and like we should be able to make it simpler than if/else-with-try-except-try-except)

[mcalmer]

yes, we try to convert to the real type int, float or string.
There may special keys which always must be converted to a specified type.
Example: there is a password and you decide to use "1234" as password. We want it to be a string, but that mechanism would convert it to a int if we would not have the convert_table.

[meaksh]

Besides of the comments made by Alex and Marek, this looks good to me.

[rjmateus]

instead of having this in the code, should we add an extra collum to the table to specify who the value should be interpreted?
Like int, string, etc?

[Serp1co]

Speaking for the Java side:
I don't think it's necessary, we have to know the data type beforehand, no dynamic type parsing.