Customizations in the detection of the current color theme in colorThemeInit.vm can result in wrongly cached less compiled resources

Through a quite complex customization of skin & color theme variables, I have obtained a case where style.less.vm (style.css) is added in the less compilation cache with one color theme as a key while the colors in it are actually the ones of another color theme.

After investigation, I found that:

• when the compiled less resources are put in the cache, the key for the cache entry is built with the code from CurrentColorThemeGetter.java#L86
  • this code checks the color theme by only taking into account request.colorTheme and the current user's preference (which fallsback on wiki color theme, I guess - not sure how the space color theme is taken into account here...)
• however, this color theme that was detected like this is then never actually set when compiling the resource in the compute function here AbstractCachedCompiler.java#L137. The compilation is responsible of fetching its own color theme. For XWiki resources (for example style.less.vm), this is done by using colorThemeInit.vm .
• thus, the cache key and the actual color theme used by the cached css will only be in sync if the current color theme is detected in exactly the same way by colorThemeInit.vm and by CurrentColorThemeGetter.java#L86 .

Thus, it's not actually possible to customize colorThemeInit.vm to make a different detection of the color theme, unless the CurrentColorThemeGetter.java is customized along with it. Failing to do so can endup in a wrong association of a theme as a cache key with the colors.