extended request options to support passing metadata match criteria

[wbpcode]

Signed-off-by: wbpcode comems@msn.com

Commit Message:

extended request options to support passing metadata match criteria

Additional Description:

Extended request options to support passing metadata match criteria. Check #15163 for more info about that why we need this PR. This PR is just a possible solution. I would be willing to modify it if there is a more elegant solution.

Risk Level: Low.
Testing: Added.
Docs Changes: N/A.
Release Notes: N/A.

[wbpcode]

/retest

[repokitteh-read-only]

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #15863 (comment) was created by @wbpcode.

see: more, trace.

[zuercher]

Thanks! See my comment below. Otherwise this looks good.

[zuercher]

I think this method should follow the example of setHashPolicy and accept a const envoy::config::core::v3::Metadata&. That way callers don't need to use the implementation of MetadataMatchCriteria and aren't tempted to provide their own implementation.

[wbpcode]

@zuercher Thanks. 😄
I chose to pass MetadataMatchCriteria instead of envoy::config::core::v3::Metadata because of the following reasons:

1. In some cases, we can directly reuse the MetadataMatchCriteria from the route.

auto options = 
  RequestOptions().setsetMetadataMatchCriteria(decoder_callbacks_->route()->routeEntry()->metadataMatchCriteria());

2. The MetadataMatchCriteria is generally fixed when we send http requests to external services via http calls in a filter. The MetadataMatchCriteria may change only when the configuration changes. Passing the MetadataMatchCriteria directly allows the developer of filter to decide if the MetadataMatchCriteriaImpl object needs to be constructed, avoiding the need to reconstruct the MetadataMatchCriteriaImpl object each time a request is sent.

[zuercher]

I discussed this briefly with another maintainer and the conclusion was that AsyncClient is one of the primary interfaces that a user of envoy as a library has to contend with. So I still think it would be better to limit this to using the proto types used to configure the feature for a route. Perhaps adding a method on the RouteEntry that allows access to the metadata_match proto objects would make it easier to implement your use case?

[wbpcode]

🤔 I agree with you, we can improve this part later.

[wbpcode]

Only one commit. I refactored it to create a cleaner implementation.

[zuercher]

Nice! I had one small comment, but otherwise looks good to me.

[zuercher]

Thanks!

[zuercher]

@alyssawilk can you take a second pass?

[alyssawilk]

Code and tests look great!
@ggreenway is this worth a release note, or do you think it's fine as is.

[ggreenway]

@alyssawilk did you mean @zuercher ?

Either way, I took a look; I don't think there's any public-facing change, so probably fine with no release note.