Correctly Propagate Errors from Drop Entities

[travis-bowen]

During drop commands, Apache Polaris would make assumptions based on the entity type as to why the entity could not be dropped which could lead to incorrect user error messaging and handling.

Here I tackle updating error handling for DropTable, DropNamespace, and DropView.

The Catalog API javadocs by Iceberg indicate false should indicate [TableNotExists] (and simila for View) (https://github.com/apache/iceberg/blob/a8ece055ba93adc0c046db29b6b7b5edaf35d4da/api/src/main/java/org/apache/iceberg/catalog/Catalog.java#L292).

For Namespaces it's less clear, but I assume the same holds and we treat it to follow the same logic that false = Not Found in CatalogHandlerUtils.

Before
Any non success in Polaris's IcebergCatalog impl would return false.
Polaris's CatalogHandlerUtils would interpret this false to mean the entity did not exist and would throw the appropriate does not exist error

However, the reason that it returned false, may not truly be that it didn't exist.

After
The IcebergCatalog impl in Polaris uses the return status of the persistence result to determine whether or not the drop failure was due to being not found. If not found, it returns false per the interface definition, which the CatalogHandlerUtil transforms into the appropriate not found exception. Otherwise it throws it's own error corresponding to the cause.

Ran tests locally + S3 Tests with drop

Checklist

• 🛡️ Don't disclose security issues! (contact security@apache.org)
• 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
• 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
• 💡 Added comments for complex logic
• 🧾 Updated CHANGELOG.md (if needed)
• 📚 Updated documentation in site/content/in-dev/unreleased (if needed)