Performance: Optimize handling of content type updates

[kjac]

Prerequisites

• I have added steps to test this contribution in the description below

Description

This PR aims at optimizing how content type updates are handled.

Essentially, content type changes can be divided into "destructive" and "constructive" categories - see this PR for details.

Claude has decided to call these changes "Structural changes" and "Non-structural changes", respectively. That's a less dramatic naming, so let's stick with that 😀

We can use these categories to determine the impact of content type updates.

For structural changes, we need to:

1. Rebuild the published content cache (in the database) for the content type.
2. Flush the in-memory cache for published content.
3. Reindex all content based on the content type.

For non-structural changes, we only need to flush the in-memory cache for published content. The content cache in the database can be reused, and the Examine indexes remain unaffected.

As-is, all content type updates are treated the same, which means even changing a name or description triggers all of the above.

Additional changes

As part of this effort, I have also added a few additional optimizations to the content type change handling:

• Use the configured batch size for reading content.
• Use the in-memory published status cache for checking the publish status of content.

Test results

I've been testing this on a local database with ~10000 pages of the same content type.

• Without this PR, any content type change takes ~17 seconds to complete.
• With these PR, a structural change takes ~9 seconds to complete, while a non-structural change takes ~0.02 seconds to complete (it is now reduced to a simple save operation).

More test results

On a local database with ~70000 pages of the same content type in 10 different languages, the results are very similar.

• Without this PR, any content type change takes ~500 seconds to complete.
• With these PR, a structural change takes ~230 seconds to complete, while a non-structural change still takes ~0.02 seconds to complete.

Interestingly, the bulk of time now seems to be spent rebuilding the published content cache in the database. This means we have another optimization opportunity by skipping the rebuild (or rebuilding on a background thread) and handling cache misses at runtime.

Co-authored by Claude 🤖

[AndyButland]

I've made a few changes and additions to the PR @kjac, so please see below to make sure you are happy with them and agree they are all necessary. I've tested and see the expected updates happening - content is still successfully retrieved from the cache and depending on the type of updates made, I'm seeing the expected calls to invalidate caches.

Here the changes made during review:

1. Auto-factory-aware converted cache clearing (ContentTypeCacheRefresher)

When using InMemoryAuto models builder mode, WithSafeLiveFactoryReset resets the entire model factory - invalidating ALL compiled model types, not just the changed ones. This means selectively clearing only specific content type IDs from _publishedContentCache is insufficient: parent content of different types would remain cached as stale instances withinvalidated model types, returning null.

I picked this up as I had the following code in my view:

var defaultCurrency = Model.Parent<Products>().DefaultCurrency;

And after a content type update - structural or non-structural Model.Parent<Products>() would return null.

The fix checks _publishedModelFactory is IAutoPublishedModelFactory and uses:

• Auto mode: ClearConvertedContentCache() (full clear) - because the factory reset invalidates all model types
• Non-auto mode: ClearConvertedContentCache(contentTypeIds) (selective) - because model types are stable, only affected types need clearing

2. Do the same for DataTypeCacheRefresher

I found the same issue if I changed a data type used on a document type that a rendered page is based on, and applied a similar fix,

3. Additional test coverage

I added some unit tests and a few integration tests to increase code coverage for the logic introduced.

4. IOptionsMonitor.OnChange memory leak fix

See inline comment on this.

ContentTypeIndexingNotificationHandler subscribed to IOptionsMonitor.OnChange in its constructor but never disposed the subscription. Since notification handlers are transient, each instantiation leaked a subscription.

Fixed by storing IOptionsMonitor<IndexingSettings> and reading .CurrentValue at call time instead of subscribing to changes.

5. Added a migration to rebuild HybridCache

Pre-existing HybridCache entries lack the new ct:{id} / mt:{id} tags needed for tag-based eviction. Added a migration that clears and re-seeds the in-memory cache using ClearMemoryCacheAsync.