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
submitUnbatchedTask("remove snapshot deletion metadata", new RemoveSnapshotDeletionAndContinueTask(deleteEntry, repositoryData) {
            @Override
            protected SnapshotDeletionsInProgress filterDeletions(SnapshotDeletionsInProgress deletions) {
                final SnapshotDeletionsInProgress updatedDeletions = deletionsWithoutSnapshots(
                    deletions,
                    deleteEntry.getSnapshots(),
                    deleteEntry.repository()
                );
                return updatedDeletions == null ? deletions : updatedDeletions;
            }
            @Override
            protected void handleListeners(List<ActionListener<Void>> deleteListeners) {
                assert repositoryData.getSnapshotIds().stream().noneMatch(deleteEntry.getSnapshots()::contains)
                    : "Repository data contained snapshot ids "
                        + repositoryData.getSnapshotIds()
                        + " that should should been deleted by ["
                        + deleteEntry
                        + "]";
                listenersHandler.accept(deleteListeners);
            }
        });
    }
    /**
     * Handle snapshot or delete failure due to not being master any more so we don't try to do run additional cluster state updates.
     * The next master will try handling the missing operations. All we can do is fail all the listeners on this master node so that
     * transport requests return and we don't leak listeners.
     *
     * @param e exception that caused us to realize we are not master any longer