Today we log a "deleting snapshots [...] from repository [...]" message at INFO level [almost the first thing](https://github.com/elastic/elasticsearch/blob/dfaec0dbf0c8a0ba2912381334019725848f1f5a/server/src/main/java/org/elasticsearch/snapshots/SnapshotsService.java#L1886-L1888) when we start the deletion. However, the requested snapshots may not exist or they may be wildcards to be matched against actual snapshots. In these cases, the log message is either misleading or insuffiicent. Instead we should log the message after we have successfully added the delete to the cluster state similar to how the [logging works for snapshot creation](https://github.com/elastic/elasticsearch/blob/f77c16b78bab5e9f3ee24974aeba408e254e8c94/server/src/main/java/org/elasticsearch/snapshots/SnapshotsService.java#L3804).
server/src/main/java/org/elasticsearch/snapshots/SnapshotsService.java
leaveRepoLoop(deleteEntry.repository());
                assert readyDeletions.stream().noneMatch(entry -> entry.repository().equals(deleteEntry.repository()))
                    : "New finalizations " + newFinalizations + " added even though deletes " + readyDeletions + " are ready";
                for (SnapshotsInProgress.Entry entry : newFinalizations) {
                    endSnapshot(entry, newState.metadata(), repositoryData);
                }
            }
            
            
            startExecutableClones(SnapshotsInProgress.get(newState), null);
        }
        /**
         * Invoke snapshot delete listeners for {@link #deleteEntry}.
         *
         * @param deleteListeners delete snapshot listeners or {@code null} if there weren't any for {@link #deleteEntry}.
         */
        protected abstract void handleListeners(@Nullable List<ActionListener<Void>> deleteListeners);
        /**
         * Computes an updated {@link SnapshotsInProgress} that takes into account an updated version of
         * {@link SnapshotDeletionsInProgress} that has a {@link SnapshotDeletionsInProgress.Entry} removed from it
         * relative to the {@link SnapshotDeletionsInProgress} found in {@code initialState}.
         * The removal of a delete from the cluster state can trigger two possible actions on in-progress snapshots:
         * <ul>
         *     <li>Snapshots that had unfinished shard snapshots in state {@link ShardSnapshotStatus#UNASSIGNED_QUEUED} that
         *     could not be started because the delete was running can have those started.</li>
         *     <li>Snapshots that had all their shards reach a completed state while a delete was running (e.g. as a result of
         *     nodes dropping out of the cluster or another incoming delete aborting them) need not be updated in the cluster
         *     state but need to have their finalization triggered now that it's possible with the removal of the delete
         *     from the state.</li>
         * </ul>