feat(lexicon): migrate config key/value

[ArtificialOwl]

Allow a rename of config keys, with a migration of linked values
also, using old config key will returns value from new config key

migration can also be initiated using:

./occ config:list --migrate [<appId>]

• tests

---

adding to CoreConfigLexicon.php the entry:

     new ConfigLexiconEntry('key123', ValueType::STRING, '', lazy: true, rename: 'key000'),

will returns:

$ ./occ config:app:get --details core key000
  - app: core
  - key: key123
  - value: my_value_in_database
  - type: string
  - lazy: true
  - sensitive: false

[come-nc]

Looks promising, I can’t wait for the tests.

[codecov]

❌ We are unable to process any of the uploaded JUnit XML files. Please ensure your files are in the right format.

[ArtificialOwl]

@nickvergessen @susnux

what you are looking for is:

	new ConfigLexiconEntry('new_key', ValueType::BOOL, rename: 'old_key', options: ConfigLexiconEntry::RENAME_INVERT_BOOLEAN),

[provokateurin]

I think "alias" is not a good name, as it doesn't make clear the old keys are deprecated.

[provokateurin]

LGTM, but I'm a bit confused why almost all changes to AppConfig/UserConfig are duplicate. I am pretty sure, that over time the implementations will deviate more and more and this calls for painful bugs. Would it be possible to have a base class with the shared logic and have each of them inherit from it? @ArtificialOwl

[ArtificialOwl]

LGTM, but I'm a bit confused why almost all changes to AppConfig/UserConfig are duplicate. I am pretty sure, that over time the implementations will deviate more and more and this calls for painful bugs. Would it be possible to have a base class with the shared logic and have each of them inherit from it? @ArtificialOwl

Could be, but not sure it is the purpose of this PR

[provokateurin]

You are right, but it makes the problem worse and I feel like there will be no improvement later if we ignore it now.

[ArtificialOwl]

I am all for avoiding duplicate code but, from my point of view, there is enough difference between AppConfig and UserConfig that trying to link them together will make everything more complex:

• AppConfig was made before the ability to use Enums,
• sensitivity is not set as a type bit anymore in UserConfig,
• cache also includes the userId dimension,

I already added ConfigManager in that PR that contains few tools used by both classes.

What we can do is having a look at the final version of the code when moving the feature from unstable/ to public/ - that I would like to request in the next 2 weeks.

[provokateurin]

Ok, as long as this is not forgotten I'm fine with it.