usage: use existing cloud_usage index procedures to widen the key

Use the pre-existing cloud_usage procedures instead of the two added in this PR. schema-41600to41610.sql:72 created this same key with IDEMPOTENT_ADD_UNIQUE_INDEX:

  CALL `cloud_usage`.`IDEMPOTENT_ADD_UNIQUE_INDEX`(       'cloud_usage.usage_volume', 'id', '(volume_id ASC, created ASC)');

so widening it the same way keeps the table's schema history consistent.

Note the two procedures take their arguments in opposite orders:
IDEMPOTENT_DROP_INDEX is (index_name, table_name), while
IDEMPOTENT_ADD_UNIQUE_INDEX is (table_name, index_name, definition).

Author: Alpha162

engine/schema/src/main/resources/META-INF/db/schema-42210to42300.sql

@@ -646,7 +646,8 @@ CALL `cloud`.`IDEMPOTENT_ADD_COLUMN`('cloud.backup_schedule', 'isolated', 'TINYI
 
 UPDATE `cloud`.`configuration` SET `value`=CONCAT(`value`, ', backupValidationCommandTimeout, backupValidationScreenshotWait, backupValidationBootTimeout')
 WHERE `name`='user.vm.readonly.details' AND `value` IS NOT NULL;
+
 -- Widen the unique key on cloud_usage.usage_volume to include vm_id, so the two volume
 -- usage records introduced in 4.22.1 (cumulative and per-VM) can coexist. See #13399.
-CALL `cloud_usage`.`IDEMPOTENT_DROP_UNIQUE_KEY`('cloud_usage.usage_volume', 'id');
-CALL `cloud_usage`.`IDEMPOTENT_ADD_UNIQUE_KEY`('cloud_usage.usage_volume', 'id', '(`volume_id`, `created`, `vm_id`)');
+CALL `cloud_usage`.`IDEMPOTENT_DROP_INDEX`('id', 'cloud_usage.usage_volume');
+CALL `cloud_usage`.`IDEMPOTENT_ADD_UNIQUE_INDEX`('cloud_usage.usage_volume', 'id', '(volume_id ASC, created ASC, vm_id ASC)');