avoid rpc waiting too long after connection disconnected

[zhangxu19830126]

What type of PR is this?

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

Which issue(s) this PR fixes:

issue #15139

What this PR does / why we need it:

Avoid rpc waiting too long after connection disconnected. Currently, when a broken link is detected, all the futures waiting for a response wait until the ctx times out

[matrix-meow]

@zhangxu19830126 Thanks for your contributions!

Pull Request Review:

Title:

The title of the pull request is clear and concise, indicating the purpose of the changes made.

Body:

The body of the pull request provides relevant information about the type of PR, the specific issue it addresses, and the reason for the changes made. It is structured and informative.

Changes:

1. In the makeAllWaitingFutureFailed function in backend.go, a new condition has been added to handle cases where a future is waiting for a response but the connection is closed. If the future is still waiting, it is added to a list for further processing. However, if the future is no longer waiting, the messageSent function is called with the backendClosed parameter.

Feedback and Suggestions:

1. Potential Issue - Incomplete Handling: The addition of f.messageSent(backendClosed) when a future is not waiting may lead to unexpected behavior. It's important to ensure that calling messageSent in this scenario does not have unintended consequences. It would be beneficial to review the logic and potential side effects of this change thoroughly.

2. Code Optimization - Error Handling: Consider adding error handling or logging mechanisms to handle any issues that may arise when calling messageSent(backendClosed). This will help in identifying and resolving any potential errors or bugs more effectively.

3. Code Readability - Comments: Adding comments to explain the purpose of the new condition and the messageSent function call can improve code readability and help other developers understand the intention behind the changes more easily.

4. Testing - Unit Tests: Ensure that appropriate unit tests are added or updated to cover the new condition and the messageSent function call. This will help in verifying the correctness of the changes and prevent regressions in the future.

5. Security Concern - Connection Closure Handling: Verify that closing the connection and calling messageSent(backendClosed) does not introduce any security vulnerabilities, such as potential resource leaks or unauthorized access. Conduct a security review to address any security implications of this change.

6. Performance Optimization - Efficiency: Evaluate if there are any opportunities to optimize the code for better performance, especially in scenarios where multiple futures are processed. Consider benchmarking the changes to ensure they do not introduce any performance degradation.

By addressing the potential issues and following the suggestions provided, the quality and reliability of the codebase can be improved, ensuring a more robust and secure implementation.