Enhance boost::asio strategy

[Changdrew]

Allow for every asio call to resume on any available worker thread

[googlebot]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[Changdrew]

@googlebot I consent.

[margocrawf]

@googlebot I consent.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Changdrew]

@cfryanr Could you take a look at this if/when you have time? We'd love your input.

We are unsure of how to obtain test coverage of filter chain matching with respect to the refactor.

[cfryanr]

Hi @Changdrew and @margocrawf,

Nice job.

While looking at the diffs to understand what you had done, I noticed some dead code, so I pushed a commit to remove the dead code.

It looks like you're asking about the lost test coverage from when you removed service_impl_test.cc. It appears that you could bring it back as async_service_impl_test.cc and adjust those tests to make them unit tests of your new Check function. In order to call your new Check function, you need the following arguments to be created by your test:

• a request and a response, which the old test had
• a vector of authservice::filters::FilterChain: it seems like you could create an instance of config::FilterChain by calling its default constructor and then calling its setters to fill in the minimum required stuff, then you could pass it to the constructor of FilterChainImpl to make one of those, and then stick that into a vector.
• config::TriggerRule: seems like you could make one with the default constructor and then call the setters to add the same trigger rules that are in valid-config.json.
• an ioc and a yield: check out this example from my new commit of making oic and yield objects for another test by writing a simple test helper function called OidcFilterTest::ProcessAndWaitForAsio and then calling it from each test. You might want to try writing another similar little test helper function.

Once you've got all those things created in your test setup, then you can call Check. It appears that those tests just wanted to vary the request url and confirm that the configured trigger rules caused the right responses.

Let me know if that helps, or if you need any help trying that.

Thanks!

[istio-testing]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Changdrew To complete the pull request process, please assign liminw You can assign the PR to them by writing /assign @liminw in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/istio-ecosystem/authservice/blob/master/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[cfryanr]

@googlebot I consent!