SLING-11716 ability to cache the results of a caconfig lookup

[joerghoh]

• cache successful resolutions and avoid duplicate resolutions of the same resource (path)
• updates to a more recent version of the ResourceResolver API
• the feature is turned off by default

I did a small benchmark (a series of a few hundred requests in a serial manner against an AEM WKND sample page), and found that with this feature enabled there was a cache-hit ratio of approx 75% for the results of caconfig resolutions, resulting in an overall 10% improvement in page rendering time and throughput.

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[stefanseifert]

lgtm in general, some remarks:

• making it configurable with default switched off is not really helpful - either we consider this caching safe then we can enable it by default - or if not, what can we do to make it safe
• when may this caching be harmful? i see two use cases
  • you have a long-running resource resolver e.g. in an OSGi service. this is an anti-pattern, but sometimes required e.g. if you are listing for resource change events.
  • you are actually writing caconfig in your current request and reading it later (most time this is a rare use case)
• maybe instead of having an OSGi configuration we should add a switch to the caconfig API where you can disable the caching if you are using caconfig in one of this use cases
• more cosmetic: we should adapt the pattern to build cache keys to use separator chars which are not allowed in JCR paths and not "--" - to be on the safe side.

[stefanseifert]

see previous comment