[Refactor] Remove the notion of SecurityRequestChannel

[peternied]

Coming from [1] where this new interface was added.

This class is meant to send back a response through the channel that a current request has. As originally built up responses could be triggered from deep in code paths around the backend registry or authenticator implementations. As more and more refactoring was done these changes transitioned to passing back a response which would be used it if was found.

This model of checking if a response has already been created and should be sent to the client seems to be an obvious replacement for the current too permissive access to the request channel that many parts of the security plugin has.

Exit Criteria

• Find all places where a RestChannel is being passed as parameter, invert the flow of control so that method passes back out a Optional<SecurityResponse>
• Delete the SecurityRequestChannel class and do the same process as above, providing Optional<SecurityResponse> as a return value for functionality that was directly using the channel. All instance of SecurityRequestChannel should be replaced with SecurityRequest.
• Make sure that usage of sendResponse() are replaced in such a way that where and when the response is triggered is from the source of the request, such as the handler wrapper in the SecurityRestFilter or the AuthenticatingVerifier.

---

• [1] Expanding Authentication with SecurityRequest Abstraction #3430

[stephen-crawford]

[Triage] Hi @peternied, thank you for filing this issue. This issue has a clear goal and closure criteria.

[d-wwwang]

I can take a jab at this!

[peternied]

@d-wwwang Sure - I'll assign this to you, looking forward to seeing a PR for this, thanks!