HAR File wikipedia: https://en.wikipedia.org/wiki/HAR_(file_format)

Only official looking doc I could find was https://w3c.github.io/web-performance/specs/HAR/Overview.html

Goal of this issue is to support Recording and exporting of HAR files,
of course it doesn't have to be a file to which we export,
but in the most common use case it will be.

This feature can be used by:

• any developer to help get insights in the traffic flowing through their rama-based client/server/proxy
• some (UA emulation related) rama tests regarding http data preservation (e.g. header casing, order, pseudoheaders, cookies, ...)

Requirements

• Add a new module har to https://github.com/plabayo/rama/tree/main/rama-http/src/layer where:
  • You add a HARExportService and HARExportLayer.

Both service and layer will take the following input:

• a Trigger trait, for now probably only implemented for FnOnce + Clone? Used to create a future (signal) to toggle between record and stop, where on stop the data is exported

The service starts in stopped modus (== not active) and is to be activated once signal is true, this can be spawned (gracefully) as a task really where the service just keeps track of an AtomicBool. Important is that that background tasks does exit in case the context is cancelled.

When the service is in record mode it will need to buffer each incoming http request in a prepared manner, har-ready.

This data can be kept already in a custom struct format (with these structs being serde::Serialize+Deserialize).

When the toggle stops the record it will need to serialize the buffer as a json blob and write it to the Writer, which is basically just an ascyn io writer.

Required input for the Service/Layer:

• Trigger object
• Writer

Custom options for the service/layer:

• meta information such as service info, author info, ...
• custom comments

This feature should also be well unit tested.

We also require an Example file which inspects the har file exists and is valid (can be as basic as just verifying the default format, not need to have 100% fail proof test. If the file exists, and it is a valid json object, which contains the expected root object and entries, where one entry can be verified a bit more in depth, it is probably good enough for what that e2e example test is concerned.