HA: a refused CREATE INDEX that replaces an existing index (withReplaceIfIncompatible) still quarantines the leader #10569

Follow-up of #10506.

#10506 moves the clean-up of a failed CREATE INDEX build inside its schema session, so on a Raft leader a refused build (for example a duplicate key met after some batches were committed) no longer quarantines the database: the files the build created are dropped before the session decides, and the session finds nothing left behind.

One path keeps quarantining, on purpose: a build made with withReplaceIfIncompatible(true) (the replace of an existing index on the same properties). TypeIndexBuilder.create() drops the index it replaces inside the same session, before the build starts. When the build is then refused, that drop is a change on the leader only - every other node still holds the replaced index's files - so RaftReplicatedDatabase.unpublishedSchemaChange now treats a recorded DROP of a file the session did not create as an unpublished change and quarantines (#10506 added that check; before it, the quarantine on this path came only from the new index's buffered pages). After the session, restoreReplacedIndex builds the old index again in a session of its own.

So a refused replacing CREATE INDEX still costs the leader a resync (UNPUBLISHED_SCHEMA_CHANGE), where it should cost the caller only an error.

Possible fix: either drop the replaced index only once the new one is built and verified (not possible as-is: LocalDocumentType.indexesByProperties holds one index per property set), or let a refused replacement end its session with the replaced index restored and publish that net state (remove old file, add restored file, schema), making sure the buffered pages of the failed build, which name files that are gone, are not shipped.

Covered today by Issue10506RefusedIndexBuildTest.aRefusedReplacingBuildDroppedAnIndexOtherNodesStillHoldAndIsQuarantined (ha-raft), which pins the quarantine as the safe answer until this is fixed.