Warn operators before an index definition change triggers a RavenDB index rebuild #6015

Describe the suggested improvement

Is your improvement related to a problem? Please describe.

When an index definition changes, RavenDB builds a side-by-side replacement of the index at the next start-up. On a large database the rebuild can take days. ServiceControl deploys its indexes at start-up (IndexDeployment.CreateIndexesAsync) and gives the operator no signal beforehand, either during the upgrade or in the logs before the rebuild starts.

Locked indexes are a second problem. If an operator locked an index, for example after migrating it to Lucene, RavenDB ignores the new definition without any warning. The index keeps the old definition, while the new version may already query fields that only the new definition provides.

6.20.0 caused both: the audit MessagesViewIndex and MessagesViewIndexWithFullTextSearch definitions changed, and operators who unlocked those indexes on 6.21.2 were surprised by the rebuild.

Repository-level guards such as #6013 help developers notice a definition change. They do nothing for an operator who is upgrading.

Describe the suggested solution

Before the IndexCreation.CreateIndexesAsync call in src/ServiceControl.RavenDB/IndexDeployment.cs, compare each index with the definition on the server using IndexHasChangedOperation. That comparison uses the definition after the search engine has been resolved. Then:

• Log at warning level each index that will be rebuilt, with the number of documents in the collections it covers, so the impact is visible before the rebuild starts.
• Log at error level each locked index (LockedIgnore / LockedError) whose definition differs, and say that the operator must unlock it for the change to apply.
• Consider failing start-up when a rebuild would happen, unless the operator opts in with a setting (for example AllowIndexRebuild). This turns a silent multi-day rebuild into a deliberate decision.
• Consider showing the same information during an upgrade in the installer / ServiceControl Management, ideally before the instance is upgraded.

Describe alternatives you've considered

• Relying only on upgrade-guide entries: these depend on every index change being documented, and 6.20.0 shows that does not always happen.
• Repository-level checks (approval tests, CI gates): they help developers, not operators.

Additional Context

• Related PR: Approve RavenDB index definitions to catch changes that trigger a rebuild #6013 (approval tests for index definitions)
• IndexDeployment.CreateIndexesAsync already reads the existing definitions with GetIndexesOperation to keep the search engine set on each index, so that information is available at this point.