[BugFix] Fix transaction stream load TXN_IN_PROCESSING error (backport #54959)

[mergify]

Why I'm doing:

Users occasionally encounter the exception TXN_IN_PROCESSING when using transaction stream load. TXN_IN_PROCESSING means someone is holding the StreamLoadContext lock and do something, and the new request can't be processed concurrently. This mechanism is designed to prevent the client from sending concurrent requests. But the exception also happens even the client sends requests sequentially which does not meet expectations. There are two possible reasons:

1. there is a background thread _clean_stream_context to check and clean the timeout load periodically. It will hold the StreamLoadContext lock before each check. So it can conflict with the load request.
2. when the last load finishes, it first sends the response to the client, and then releases the lock. It is possible for the client to receive the response before the server releases the lock and then send the next request. When the next request reaches the server, the lock may still not have been released, leading to this issue.

The second is introduced by #53564 recently, but this problem has been reported before it. So the first should be the primary reason, and I have verified it in a user's environment.

What I'm doing:

1. for cause 1, reduce the conflict by removing the lock when checking the timeout. only hold the lock when aborting it because of timeout
2. for cause 2, [BugFix] Fix transaction stream load lock leak #53564 is to solve the lock leak when there is no normal response, but if the request is normal, should release the lock before response.

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr