skip unlock remote table for remote txn

[iamlinjunhong]

What type of PR is this?

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

Which issue(s) this PR fixes:

issue #16121

What this PR does / why we need it:

skip unlock remote table for remote txn

[matrix-meow]

@iamlinjunhong Thanks for your contributions!

Pull Request Review:

Title:

The title of the pull request is clear and concise, indicating the specific change being made.

Body:

The body of the pull request is minimal but provides essential information about the type of PR and the related issue number.

Changes:

1. In the service_test.go file:

   • A new test function TestIssue16121 has been added to test a scenario related to issue [Bug]: mo hung in sysbench write only test with 10w basic data loop test #16121.
   • The test involves locking and unlocking operations on two services (l1 and l2).
   • The test simulates changing the lock table from local to remote and then unlocking a transaction on the remote table.

2. In the txn.go file:

   • A new function canSkipTable has been added to determine if a table can be skipped during transaction closure.
   • The activeTxn struct's close method has been modified to skip unlocking a table if it is a remote lock table and the service IDs do not match.

Feedback and Suggestions:

1. Code Optimization:

   • The logic in the canSkipTable function can be simplified by directly returning the condition instead of using an if-else block. For example:

     canSkipTable := func(serviceID, txnServiceID string, l lockTable) bool {
         return serviceID != txnServiceID && l.(*remoteLockTable) != nil
     }

2. Error Handling:

   • It's important to handle potential errors that may occur during the test execution in TestIssue16121. Ensure that any errors are properly caught and reported to provide meaningful feedback.

3. Security Concern:

   • The change in the txn.go file introduces a potential security issue. When skipping the unlock operation for a remote lock table, it's crucial to ensure that this behavior does not compromise data integrity or lead to unauthorized access. Consider adding additional checks or validations to prevent unintended consequences.

4. Documentation:

   • It would be beneficial to include comments or documentation explaining the purpose and rationale behind the changes made in both the test function and the canSkipTable function for better code understanding and maintenance.

5. Testing:

   • Ensure that the new test case TestIssue16121 covers all relevant scenarios and edge cases to validate the behavior accurately.

6. Consistency:

   • Make sure that the naming conventions and coding style are consistent with the existing codebase for better readability and maintainability.

By addressing the above points, the code quality, security, and maintainability of the pull request can be improved.

ut failed