[ramonsmits]

Partially addresses:

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

IndexDeployment now logs what it decides at start-up:

• one line per database with its static index search engine setting, or that none is set
• one line per index with the engine it uses and whether the engine is set on the index or inherited from the database
• a warning for each index that RavenDB rebuilds because its definition changed, with the differences that cause the rebuild
• a warning for a locked index whose definition is unchanged
• an error for a locked index whose definition changed. Setup then fails with an exception that names the locked indexes, because the change is not applied until the operator unlocks the index. Before, a LockedIgnore index started silently with the old definition, and a LockedError index failed with a RavenDB exception.

Not included, left for #6015: the number of documents the rebuild covers, a setting that refuses a rebuild at start-up, and the same information in ServiceControl Management before the upgrade.

[ramonsmits]

@danielmarbach I guess the intent here is to report if an index has has a (un)supported search engine type. I think I'm ok with these having the same log template for both states but with a different log level just as is happening later in the code . I'm not sure that if we would have used log tempates

Not a fan of the {Note} as its a log template argument but nothing really against it.

[danielmarbach]

@ramonsmits if you prefer, else that's also fine. I care mostly about the other small improvements

[ramonsmits]

CI keeps failing, create CI fix:

• Pin the Azure region for Service Bus and Storage test resources #6089