enhancement: introduce theme processing

[fschade]

Description

we've set up a flexible configuration system with the theme.json file, benefiting not just web clients but also those on mobile and desktop platforms.

when new customization options come into play, it can be tough for users who've already personalized their themes, possibly messing up the experience.

this challenge also affects developers and administrators, who then need to communicate extensively to introduce new theme properties.

to tackle this, i suggest an automatic injection of new properties/options into the user's theme.json file, ensuring a smooth merging of default and custom themes.

Basically thats exactly what this pr does, the themes get proccessed in the following order:

themeDefaults < baseTheme < brandingTheme

• themeDefaults: contains all the default values, this is guaranteed to exist
• baseTheme: contains the base theme from the theme fs, there is no guarantee that it exists
• brandingTheme: contains the branding theme from the theme fs, there is no guarantee that it exists

which results in the final theme.json.

One of the benefits having it that way, is the ability to set specific json key values for the brandingTheme only, for example after a logo update.

{
	"clients": {
		"web": {
			"defaults": {
				"logo": {
					"login": "themes/_branding/49308105.jpeg",
					"topbar": "themes/_branding/49308105.jpeg"
				}
			}
		}
	},
	"common": { "logo": "themes/_branding/49308105.jpeg" }
}

we've decided to make it NOT backward compatible, the breaking change is that the user has to re-upload the custom logo, thats it. The previous approach copied the whole theme.json, therefore it contained ALL key value combinations which makes a backward comp fix nearly impossible and is not in relation to the required work.

Related Issue

• Fixes [ocis] Theme pre-processing and automatic injection of new theme options #8966

How Has This Been Tested?

• unit tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Add more tests
• Test manually
• Wait for Theme capability cs3org/reva#4702

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[mmattel]

Please consider adding a documentation in the web servcie readme.md

[micbar]

Small nitpicks, thumbs up for the rest.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
37.1% Coverage on New Code
6.4% Duplication on New Code

See analysis details on SonarCloud

[fschade]

@individual-it, @saw-jan, the following test is flaky:

https://drone.owncloud.com/owncloud/ocis/35485/33/6 RED
https://drone.owncloud.com/owncloud/ocis/35487/33/6 GREEN

follow up pr

[saw-jan]

@individual-it, @saw-jan, the following test is flaky:

https://drone.owncloud.com/owncloud/ocis/35485/33/6 RED
https://drone.owncloud.com/owncloud/ocis/35487/33/6 GREEN

Probably due to a race-condition. we have an open issue for this and trying to figure out the proper way to make it solid