Fix duplicate key constraint when reverting chain shard changes

[erayack]

Description

This PR fixes issue #6196 by implementing a robust backup naming system that prevents duplicate key constraint violations when reverting chain shard changes.

Problem

When changing a chain's shard using graphman chain change-shard, the existing chain is renamed to <chain>-old. However, if a subsequent attempt is made to revert the chain's shard back to the original shard, the operation fails due to a unique constraint violation because <chain>-old already exists in the database.

Solution

• Robust backup naming: Implemented next_backup_name() function that generates unique backup names by appending numeric suffixes when conflicts exist
• Backup reuse optimization: When reverting to the original shard, the system now reuses the existing backup instead of creating a new one
• Backup preservation: Previous backups are preserved with unique names to maintain data integrity
• Logging: Added logging to track backup operations and outcomes

Changes

• Added ChainSwapOutcome struct to track the results of chain swap operations
• Implemented next_backup_name() function for conflict-free backup naming
• Enhanced change_block_cache_shard() function with robust backup handling logic
• Added detailed logging for backup operations

Testing

The fix handles the following scenarios:

1. Initial shard change (creates <chain>-old)
2. Reverting to original shard (reuses existing backup)
3. Multiple shard changes (preserves all backups with unique names)

Fixes #6196