Fix Iceberg materialized view storage table cleanup

[alexjo2144]

Description

Fixes: #20837

As well as some other edge cases which can happen if a CREATE MATERIALIZED VIEW operation fails.

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
(x) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

# Iceberg
* Fix dropping materialized views which were created before 433 when using a Hive catalog.
* Improve storage table cleanup when creating a materialized view fails.

[homar]

sorry if this is a silly question but why dropping storage table when update failed? I understand doing it when create failed, but for update im not so sure.

[alexjo2144]

So the case here is when you do a CREATE OR REPLACE MV and there is a MV with that name already. In that case we create a new storage table. If the update fails, the new storage table is cleaned up here because it is not referenced by the MV.

There is something missing here though, when you do a replace the old storage table is not cleaned up on a successful operation. Should do that here.

[findepi]

LGTM but mind @homar 's comment

[alexjo2144]

@findepi can you kick off a test with secrets?

[ebyhr]

/test-with-secrets sha=cb0727336de48b9c28841c7aaf2f34fda99d8c38

[github-actions]

The CI workflow run with tests that require additional secrets has been started: https://github.com/trinodb/trino/actions/runs/8147198341

[alexjo2144]

Rebased but I think this should be good to go