Fix mo cloud-issue-3298 (#16254)

[triump2020]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #
https://github.com/matrixorigin/MO-Cloud/issues/3298

What this PR does / why we need it:

1. When open PK deduplication against txn's workspace, should skip mo_tables, mo_columns, mo_database .
2. When open PK deduplication or not , make sure it can pass BVT test.

[matrix-meow]

@triump2020 Thanks for your contributions!

Pull Request Review:

Title:

The title of the pull request is clear and concise, indicating that it is fixing an issue related to "mo cloud-issue-3298."

Body:

The body of the pull request provides information on the type of PR, the specific issue being addressed, and the purpose of the changes made in the PR. It mentions that the changes are related to PK deduplication and passing BVT tests.

Changes:

1. In txn.go:

   • The changes made in txn.go involve modifying the checkDup function to skip certain conditions related to mo_tables, mo_columns, and mo_database. This change is aimed at improving the behavior when open PK deduplication against txn's workspace.
   • The condition e.isCatalog() is introduced to skip certain operations based on the type of event.

2. In load_data.result and auto_increment_2.csv:

   • The changes in these files seem to be related to test data modifications, specifically altering values in the test data files to ensure they pass the BVT test.

Feedback and Suggestions for Improvement:

1. Security Issue:

   • The changes made in the txn.go file seem to be related to skipping certain operations based on specific conditions. It's crucial to ensure that skipping these operations does not introduce any security vulnerabilities or unexpected behavior. Consider thoroughly testing these changes to prevent any potential security risks.

2. Code Optimization:

   • In the txn.go file, the condition e.isCatalog() is introduced to skip certain operations. It might be beneficial to provide a clear comment explaining the purpose of this condition to improve code readability and maintainability.

3. Test Data Modifications:

   • While modifying test data for BVT tests is essential, ensure that the changes made in the test data files accurately reflect the expected behavior and do not introduce inconsistencies that could affect the test results.

4. Consistency in Changes:

   • Ensure consistency in the changes across different files. For example, in the load_data.result file, there are changes related to dropping tables and modifying data. Make sure these changes align with the overall goal of the PR and do not introduce unnecessary modifications.

5. Documentation:

   • Consider adding comments or updating documentation to explain the rationale behind the changes made in the PR. This can help other developers understand the purpose of the modifications and facilitate future maintenance.

6. End of File Changes:

   • In the load_data.result and auto_increment_2.csv files, there are changes related to the end of the file (e.g., removing or adding new lines). Ensure that these changes do not impact the readability or functionality of the test data files.

7. Review and Testing:

   • Before merging the PR, conduct thorough code reviews and testing to ensure that the changes do not introduce regressions or unexpected behavior. Consider involving team members for additional feedback and validation.

By addressing the security concerns, optimizing the code changes, ensuring consistency, and documenting the modifications, the quality and maintainability of the codebase can be improved.