[AMORO-3413] Optimize execution order when disposing tables

[Jzjsnow]

Why are the changes needed?

Currently, when adding and deleting tables from external catalogs, the tableIdentifier is added/deleted first and then the tableRuntime is added/deleted sequentially, this may result in a scenario where tableIdentifier deletion succeeds but tableRuntime deletion fails, and the following problems further occur:

1. The web page displaying tableRuntime list for the specific catalog fails, because these tableRuntimes can not find the corresponding information in the table_identifier table;
2. tableRuntime retained in the persistence will block the re-insertion of the table, due to the unique key conflicts.

Close #3413.

Brief change log

• When calling disposeTable() to dispose of a table, we first remove the tableRuntime before removing the tableIdentifier. This follows the reverse process of the syncTable() method, where we first add the tableIdentifier and then add the tableRuntime.
• When callingdispose() to dispose of a tableRuntime instance, we first unregistry metrics, then close the optimizing processes and remove the tableRuntime from persistence.

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

• Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[zhoujinsong]

Thanks for the fix, this PR may resolve #3444 too.

[zhoujinsong]

@Jzjsnow Thanks for the work!

I have a different perspective on this issue. Wouldn't it be a better approach to delete the runtime table and the identifier table together through transaction control during the dispose phase?