fix #3957: Lister onOpen should be called before marking the connection open

[AdrianFarmadin]

Description

Fix #3957

In PodOperationsImpl class the buildAsync method is called with ExecWebSocketListener.
The ExecWebSocketListener is opening outputPipe and errorPipe in onOpen.
If the future is completed before the outputPipe and errorPipe are open, then the consumer can read from the pipes before they are open.

The pipes should be open first and then the future should be marked as complete.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[shawkins]

LGTM - but this primarily needs applied to master and can there be an update to the javadocs of our WebSocket.Builder.buildAsync to explicitly state the expectation that onOpen is called first - just to make sure that if for whatever reason we can't honor that we'll have to change the calling logic.

This happened because of eliminating the additional wait logic that was in the ExecWebSocketListener, so this is applicable to 5.11 as well.

The JDK client behavior is consistent with this change - the returned future from buildAsync will not be completed until after onOpen has been called (but that is not explicitly called out in the javadocs).

[AdrianFarmadin]

I added javadocs.

Should I create pull requests for master and 5.11 as well?

[shawkins]

LGTM

@manusa how do you usually handle porting to other branches - is that something that you usually just cherry-pick and update from there?

[manusa]

LGTM

@manusa how do you usually handle porting to other branches - is that something that you usually just cherry-pick and update from there?

I switched this to master and added the backport label. I'm still not sure how I'm going to handle these ones, since some of the selected changes are going to be hard to move to 5.12.

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication