Add k/v store for repo settings

[lunny]

replace #19400
credit @techknowlogick

[lunny]

@delvh I think I did what you want. Please review again.

[KN4CK3R]

Before we heavily start using our new user/repo/system setting tables, we should evaluate if the current database design is suitable. Currently we use something like

| reference id (repo.id/user.id int) | setting key (string) | setting value (string) |

If we add a setting with the key feature.subfeature.id for a user we need to store this string for every user we have. This could result in big pile of (unneeded) data. Sadly I did the same for the properties in the package registry, so I would call this design naïve.

This stackoverflow thread shows different ideas of how a settings system may be better designed. Additionally I would vote for different value type columns. At the moment we encode everything into strings. It may be beneficial to store values with the correct type: int(/bool) -> int, string/json -> string, ...

[lunny]

I have tried that design. But from another view of a database maintainer, it's not easy to find the value if we know the setting key and change it in the database directly. Maybe it's a smart database's responsibility to reduce storage space for duplicated keys.

@delvh done.

[wxiaoguang]

I can see that repo has "unit" config, then why do we need this?

[lunny]

I can see that repo has "unit" config, then why do we need this?

Not all configuration belongs to a unit?

[wxiaoguang]

I can see that repo has "unit" config, then why do we need this?

Not all configuration belongs to a unit?

For example?

[lunny]

Closed as currently most repository level configuration could be stored in repo_unit table.