[Bug-fix] Ignore modified table log when table has been dropped

[EmmyMiao87]

Although the table lock can control the simultaneous modification of the table by different threads.
But it cannot control the drop operation of the table by other threads.
For example, when drop table and table update occur at the same time.

1. get table object by thread 1
2. drop table by thread 2 with table lock
3. update table object by thread 1

The above process is possible.
At this time, step 3 actually operates a table that no longer exists, which will eventually cause NullPointerException.

In fact, the modified table log after the drop table can be ignored. The reason is that it is meaningless to modify information on a table that no longer exists.

Fixed #5687

Types of changes

What types of changes does your code introduce to Doris?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Code refactor (Modify the code structure, format the code, etc...)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have created an issue on (Fix Replay update replica failed when table has been dropped #5687) and described the bug/feature there in detail
• Compiling and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• If these changes need document changes, I have updated the document
• Any dependent changes have been merged

[caiconghui]

can we just simply skip replayUpdateReplica if table has been dropped. because someone may drop db, so we still need to lock catalog?

[morningman]

If this problem occurs, there is something wrong with the metadata access mechanism itself.
And this error may happen again.
I think a simpler way is to judge if table is null in the unprotectUpdateReplica() method of Catalog, return directly.

[EmmyMiao87]

can we just simply skip replayUpdateReplica if table has been dropped. because someone may drop db, so we still need to lock catalog?

Indeed, if we have to add db locks for this situation, basically table locks are of little significance.
I will consider skipping the replay log if the table does not exist.

[caiconghui]

LGTM

[morningman]

LGTM

[morningman]

LGTM