Adjust the drop table logic for Delta Lake managed tables

[findinpath]

Description

Advise the metastore to delete table data only when dealing with managed tables.

Additional context and related issues

Delta Lake same as Hive works with MANAGED and EXTERNAL table types. In case of dealing with MANAGED tables, the engine is responsible (either through delegating internally this responsibility to the metastore - HMS or doing this operation itself in case of AWS) to remove the content of the table when executing DROP TABLE table_name statements.

Release notes

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

[ebyhr]

Could you rename the argument in TestDeltaLakeSplitManager.dropTable method as well?

[ebyhr]

nit: How about renaming to deleteData? We need to guess the behavior from managedTable, but we can easily understand the behavior form deleteData.

[ebyhr]

/test-with-secrets sha=0d8691a8d20e66144e90961587c2520df73170c6

[findinpath]

Stumbled on

Error:  io.trino.plugin.deltalake.TestDeltaTaskFailureRecoveryTest.init  Time elapsed: 74.792 s  <<< FAILURE!
io.airlift.bootstrap.ApplicationConfigurationException: 
Configuration errors:

1) Error: Configuration property 'task-retry-attempts-overall' was not used

Seems to be caused by left-over stuff from 920d14c

I see that there's already a PR for this.

[github-actions]

The CI workflow run with tests that require additional secrets finished as failure: https://github.com/trinodb/trino/actions/runs/4051475639

[findinpath]

@ebyhr can you pls trigger again a build with secrets?

[ebyhr]

/test-with-secrets sha=0d8691a8d20e66144e90961587c2520df73170c6

[ebyhr]

All Databricks product tests succeeded in https://github.com/trinodb/trino/actions/runs/4054233976/jobs/6975812918. Let me merge now.