Show the use of an OSGi Config Properties to control flush actions

Customers might have complicated deployments where content may refer to other pieces of content, such as a Page might depend on a DAM asset. There's a way of controlling the dispatcher cache by leveraging the statfileslevel property to invalidate the cache when an ACTIVATE occurs however we may not want to invalidate the entire cache, or large portions of the cache when only a few resources need to be purged.

For example, if a website section /content/my-site/us/en/products leverages images from /content/dam/products, anytime an image asset in /content/dam/products is updated, we want to ensure any uses of it by web pages in /content/my-site/us/en/products are also updated. We could set a stat level of 1 that invalidates everything under /content when anything under /content changes, however this inefficient, since an update to /content/my-site/us/en/products would invalidate everything under the rest of the web site too, for example: /content/my-site/us/en/services and /content/my-site/us/en/about-us, etc.

This experiment would be to introduce an OSGi property to specify a targeted flush rule. By creating a new sling:OsgiConfig node for each flush rule set, this gives more control over the cache flush operations.

See https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html for additional details.

Start by reading the linked Dispatcher Flush Rules documentation and inspect the repository for its existing OSGi configuration and flush-action entry points. Done means a new OSGi property and sling:OsgiConfig node pattern can express targeted flush rules without invalidating unrelated site sections.

Written by the indexing model from the issue text.