Happy Eyeballs for EDS clusters

[pradeepcrao]

Commit Message:
Additional Description:

This change adds the ability to associate multiple IP addresses with one host for an EDS cluster. The connection to the upstream will be made using Happy Eyeballs if the Endpoint has more than one address.

The primary use case for this is to allow dual-stack (i.e. with both IPv4 and IPv6 addresses) endpoints as a means to migrate from IPv4 to IPv6 backends. See https://docs.google.com/document/d/1AjmTcMWwb7nia4rAgqE-iqIbSbfiXCI4h1vk-FONFdM/edit#heading=h.xzptrog8pyxf for a more detailed description.

Risk Level: Low
Testing: Added test
Docs Changes: Added Doc
Release Notes: Added release note
Platform Specific Features: N/A

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #27881 was opened by pradeepcrao.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #27881 was opened by pradeepcrao.

see: more, trace.

[pradeepcrao]

/assign @RyanTheOptimist

[RyanTheOptimist]

Nice! Though I find the idea of Happy Eyeballs without DNS to be a bit mind blowing :)

[pradeepcrao]

Nice! Though I find the idea of Happy Eyeballs without DNS to be a bit mind blowing :)

Thank you so much for the review @RyanTheOptimist !

[pradeepcrao]

/retest

[pradeepcrao]

/assign-from @envoyproxy/senior-maintainers

[repokitteh-read-only]

@envoyproxy/senior-maintainers assignee is @mattklein123

🐱

Caused by: a #27881 (comment) was created by @pradeepcrao.

see: more, trace.

[pradeepcrao]

/review @adisuissa @markdroth

[mattklein123]

Neat!

[adisuissa]

Changes LGTM!

Can you please add a comment next to the address_list_ data member, stating the underlying assumption that the first entry in the list must be the same host as address_ (better yet, add this as an assertion somewhere if possible).

[pradeepcrao]

Changes LGTM!

Can you please add a comment next to the address_list_ data member, stating the underlying assumption that the first entry in the list must be the same host as address_ (better yet, add this as an assertion somewhere if possible).

The following ASSERT fails for me in the ProtocolIntegrationTest.LogicalDns test. It appears that this assumption is not valid for LOGICAL_DNS

    void setAddressList(const std::vector<Network::Address::InstanceConstSharedPtr>& address_list) {
      address_list_ = address_list;
      ASSERT(address_list_.empty() ||
             std::find(address_list_.begin(), address_list_.end(), address_) != address_list_.end());
    }

[pradeepcrao]

Changes LGTM!
Can you please add a comment next to the address_list_ data member, stating the underlying assumption that the first entry in the list must be the same host as address_ (better yet, add this as an assertion somewhere if possible).

The following ASSERT fails for me in the ProtocolIntegrationTest.LogicalDns test. It appears that this assumption is not valid for LOGICAL_DNS

    void setAddressList(const std::vector<Network::Address::InstanceConstSharedPtr>& address_list) {
      address_list_ = address_list;
      ASSERT(address_list_.empty() ||
             std::find(address_list_.begin(), address_list_.end(), address_) != address_list_.end());
    }

Never mind, I should be dereferencing the shared_ptrs for comparison because of how these are constructed

[adisuissa]

Thanks, LGTM!

[pradeepcrao]

/restest