[Proxy] Support middleware & factor out non-proxy concerns

[bryanchriswhite]

Objective

Add a degree of freedom for proxy consumers to configure middleware functions which the proxy will call at appropriate stages in the request/response pipeline.

Origin Document

Currently, RelayServer implementations, which are responsible for the request/response pipeline, don't expose any control over the shape of or flow through it. I.e., a validation stage (function) is applied before the relay is serviced and a signing stage (function) is applied after servicing the relay but before returning the response. While the implementation of these functions may lie outside of the RelayServer implementation, it is still explicitly aware of which of them is called at what stage, with no opportunity for (re)configuration.

If we add a "middleare" concept to the RelayServer which provides sufficient hooks into significant stages of the request/response pipeline we would reduce RelayServers awareness of an unrelated concern; instead of "validate here" and "sign here", it becomes "run this [current stage]'s middleware".

We should consider whether it's necessary and/or appropriate to make the RelayerProxy aware of middleware as well. I could imagine use cases for both relayer-wide as well as RelayServer-specific middleware)

Goals

• Improve separation of concerns in the the /pkg/relayer/proxy package.
• Improve re-usability and maintainability.
• Support middleware configuration for (at least) the following request/response pipeline stages (names are illustrative only):

Stage	Description
Pre-service	Immediately after a relay request is received from an application and before taking any other action. (E.g.: relay, session, application accounting, etc. validation.)
Pre-response	After servicing the relay and hydrating the response and immediately before sending the response back to the application. (E.g.: response validation and signing)

Deliverables

• [ ] Refactor relayer pkg interface(s) as necessary to support middleware configuration.
• [ ] Refactor RelayServer implementations to utilize middleware instead of directly calling validation & signing functions.
• [ ] Refactor RelayServer consumers to provide middleware configuration(s).

Non-goals / Non-deliverables

• Refactoring RelayServer listener/handler functions beyond what's necessary to effect the middleware refactor.

General deliverables

• [ ] Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.
• [ ] Testing: Add new tests (unit and/or E2E) to the test suite.
• [ ] Makefile: Add new targets to the Makefile to make the new functionality easier to use.
• [ ] Documentation: Update architectural or development READMEs; use mermaid diagrams where appropriate.

---

Creator: @bryanchriswhite Co-Owners: @red-0ne

[Olshansk]

@bryanchriswhite I like the initative of this refactor. I moved it into our TECHDEBT iteration but lmk if you think it should be tended to sooner.

Two additional thoughts/comments:

1. Thought on naming this RelayerMiddleware under /pkg/relayer/middleware
2. Once this is done, we'll need to add a requirement/delvierable to explicitly document that middleware is where gateways can add their own custom (e.g. quality-of-service) plugins

[Olshansk]

@red-0ne to review in iteration 9 and sync with @bryanchriswhite to decide if this is necessary or not.