define request and response body access at the router service level for rhai

[Geal]

in https://github.com/apollographql/router/pull/3234 we provided a way to access Router service level requests and responses. At this step, the body is a stream of byte chunks, with no real guarantee about the format:

• it could be JSON, or something else
• it could be multipart, but not neatly cut at the multipart header (the rrouter service enforces that, but a plugin might change it)
• it could be encoded in something else than UTF8
• it could be compressed
• chunks can have arbitrarily high latency between them

Due to these issues, we do not give access to the body, until we can provide a good API to manipulate it

[garypen]

Rhai has a first class type for representing bytes: https://rhai.rs/book/ref/blobs.html

We could leverage this to think about a progressive representation such that:

First

We could provide a basic interface which provides a rhai callback function a Blob each time it is received in the router.

At this time, anyone wanting to manipulate this data from a Rhai script would be restricted to the features provided by the Blob.

Second

We could provide some utility functions which provide some common functionality for manipulating Blobs. e.g.: try to convert to JSON, try to convert to multipart, etc...

Some questions/observations:

• would the data be compressed? I thought it would be de-compressed before hitting the router_service and if it isn't, then isn't that also a problem for any rust plugins?
• high latency wouldn't be an issue for this kind of interface (or at least not more than, for example, a rust plugin)
• non UTF-8 encoding wouldn't matter at the Blob level, since it's just a collection of Bytes
• multipart would be the same kind of problem as for a rust plugin
• JSON or not, same problem in rust plugin or coprocessor or ....

It feels like this might be a good approach for at least starting to explore the problem.