Fix ConnectionHandlerImpl matching correct any address

[soulxu]

Commit Message: Fix ConnectionHandlerImpl matching correct any address
Additional Description:

• Fix Using map to store the listener in ConnectionHandlerImpl #19362 using the Network::Utility::getIpv4AnyAddress with wrong way. Utility::getIpv4AnyAddress returns a singleton of any address instance, it won't work with port parameter. This also leads to istio integration test failed Automator: update proxy@master in istio/istio@master istio/istio#37004
• Add more checks for avoid return shutdown listener when redirect.
• Add assertion ensure the redirect won't consider non-ip address.

Risk Level:low
Testing: unittest
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

Signed-off-by: He Jie Xu hejie.xu@intel.com
Co-authored-by: Yuchen Dai silentdai@gmail.com

[soulxu]

@howardjohn I don't know if there is way to test this fix on the istio side, otherwise revert the #19362 is the right choice. Hope this can fix the problem. Sorry for making this regression.

cc @lambdai @mattklein123

[howardjohn]

I can try it out hopefully sometime today

[soulxu]

/wait

[soulxu]

I can try it out hopefully sometime today

thanks

[lambdai]

Thank you! I think that is the reasonable fix

[soulxu]

/wait

waiting for istio side test.

[howardjohn]

I think its still failing...

[soulxu]

cc @ggreenway

[ggreenway]

@howardjohn can you test this branch and see if it fixes the Istio issues?

[howardjohn]

@howardjohn can you test this branch and see if it fixes the Istio issues?

We don't have the best infrastructure to test arbitrary Envoy builds right now, and the issue was not 100% reproducible (but close), but it appears to be fixed. About 90% confident (where 100% confidence will come after it lands and our CI pulls it in). Thanks for all the work here!

[ggreenway]

LGTM. @lambdai any other comments?

/wait-any

[soulxu]

@howardjohn can you test this branch and see if it fixes the Istio issues?

We don't have the best infrastructure to test arbitrary Envoy builds right now, and the issue was not 100% reproducible (but close), but it appears to be fixed. About 90% confident (where 100% confidence will come after it lands and our CI pulls it in). Thanks for all the work here!

Is that possible I compiled an envoy and upload somewhere, then I trigger by a PR on istio side to modify those address
https://github.com/istio/istio/blob/e448c96013adc84de2864c586d9012f9aad7262c/Makefile.core.mk#L130-L134

[lambdai]

LGTM. @lambdai any other comments?

/wait-any

LGTM. Thanks!

[lambdai]

@howardjohn can you test this branch and see if it fixes the Istio issues?

We don't have the best infrastructure to test arbitrary Envoy builds right now, and the issue was not 100% reproducible (but close), but it appears to be fixed. About 90% confident (where 100% confidence will come after it lands and our CI pulls it in). Thanks for all the work here!

Is that possible I compiled an envoy and upload somewhere, then I trigger by a PR on istio side to modify those address https://github.com/istio/istio/blob/e448c96013adc84de2864c586d9012f9aad7262c/Makefile.core.mk#L130-L134

the istio/proxy commits could use any commit in envoyproxy/proxy, but only envoy maintainers can create such a commit.

Also, for this particular failure, istio/proxy doesn't detect either.

[ggreenway]

@howardjohn please let us know if the istio issue is resolved, after you're able to test with this commit.

[howardjohn]

We are good to go 👍 . Thanks everyone

[soulxu]

We are good to go 👍 . Thanks everyone

thanks!