Move RequestManager to a separate package and make it more generic

[provokateurin]

• Only handle http.Request and use an http.Client for executing the requests. refactor(neon_framework): Consolidate RequestManager wrap methods and only accept http.Request #2236
• Compute cache keys on-the-fly based on the request refactor(neon_framework): Compute RequestManager cache keys automatically #2237
• Return a simple Stream and use yield instead of requiring usage of BehaviorSubject

[provokateurin]

I already have a bunch of this work locally and some is read to merge, @Leptopoda can I assign me to this issue?

[Leptopoda]

I think we should implement the cache without any serialization logic.
I.e. without the request manager. Similar to #2165, by just adding a cache interceptor.

Ideally the cache does work directly with http.Requests and http.Responses. The client that does the deserialization shouldn't care whether the data is fetched from the cache or upstream. If needed I'd rather append a header to the http.Response signaling that it was cached (I think that's what the age header is for https://www.rfc-editor.org/rfc/rfc7234#section-5.1).

That way the caching would be separate from the request manager itself where the manager would only be responsible for making the requests (maybe with different priorities ...)

[provokateurin]

Yes that's my plan eventually. With #2237 I could also move the whole logic into the cache, like I said in the initial comment on the PR.

[provokateurin]

@Leptopoda we can probably close this as we want to get rid of it entirely at some point? The other stuff now already lives in neon_http_client.