Aggregated server-side logging

[mindplay-dk]

I'd like to propose adding support for optional server-side aggregation of the logs.

I'd suggest a very simple addition to the extension.

It currently looks for the data embedded in the x-chromelogger-data.

I'm proposing an alternative header x-chromelogger-url, which would instead provide a URL, from which the client can fetch the server-side logs with a subsequent GET request for the same JSON data.

This would enable server-side implementations to store data in temp-files (or a cache, etc.) and expose server-side logs of any arbitrary size.

I would immediately add support for this to kodus/chrome-logger, which (like some implementations on other platforms) is middleware-based, making it very easy for a developer to bootstrap the logger with a single component.

This would address issues like #40 and #61, which apparently are all too common.

The default header-size limit in NGINX, for example, is much too low for ChromeLogger to be of any real use - even if we try to document our way around these issues, header-size limitations apparently exist in all sort of server-software, and developers and sys-admins usually need to debug this the hard way. It's a considerable waste of time.

Most of the server-side implementations address the header-size limitation in Chrome by introducing a ~240K limit on the size of the emitted header. That's not a good work-around, because (1) you can't be certain that other headers don't grow beyond the remaining ~16K that's left over, and (2) in some debugging scenarios you actually need the full log-data, e.g. when you need a log-entry generated near the beginning and near the end of the same request.

@ccampbell let me know if you'd accept a PR?

[mindplay-dk]

I see now that this was actually implemented in '14 in #52.

I'd like to redo it using today's APIs though, and that PR is probably too old to merge anyhow.

[mindplay-dk]

@ccampbell are you there?

I'd like to help.