Implement message logging functionality

[bbatsov]

Is your feature request related to a problem? Please describe.

Often when people encounter an issue with nREPL the best way to debug the issues is to expect the message exchange between their client and nREPL, so we/they can check whether the request and response messages are what we're expecting them to be (both in their encoded and decoded form).

Describe the solution you'd like

Ideally we'll need some way to log all messages as Clojure maps and in their encoded format (e.g. bencode) to a file. Perhaps we can have a logging middleware that checks for some :verbose key in messages and would log those. Clients can easily implement a toggle turning on/off message logging. We can probably have different options for showing the messages encoded or decoded. Likely we should have one log file per each server that goes to .nrepl/ or the current directory, so logs for different servers don't get interleaved (or we can have one log file and just prefix messages accordingly there).

Describe alternatives you've considered

CIDER has some client-side message logging functionality, but there's no easy way to inspect what happens with the message on the server's end.

This doesn't really have to be a middleware - it can also be some server config (e.g. we can add a verbose flag to start-server and just check for it on the transport level), but I think a middleware will be a more flexible solution.

Looking at #79 it seems that @pfeodrippe should be able to easy handle this. Given his work on #84 he should also immediately appreciate the importance of having this. :D

[pfeodrippe]

Definitively I'm going to tackle something about this at #84, thanks for this issue, it's gonna be a good guide! o/

[pfeodrippe]

I'm having some problems with it

1. When reading data, transport-read function is not available at FnTransport, can't see the data without changing the concrete transport implementation
2. send-fn at FnTransport is opaque

For 1, we could get the message after decoded and encode it again, but maybe it would not be representative enough of the received message.

For 2, I can compose the send-fn field (if FnTransport becomes a Record) with another function or using the reversed proposed solution for 1

Maybe would be better to snitch the data for in and out streams, but using this would require a global configuration instead per message.

Any other options to be suggested?

[bbatsov]

When reading data, transport-read function is not available at FnTransport, can't see the data without changing the concrete transport implementation

So using something like logging-transport wrapper won't work? I think this was my original idea, but I didn't think much about this.

Maybe would be better to snitch the data for in and out streams, but using this would require a global configuration instead per message.

Yeah, perhaps that'd be better. We can just add some debug/verbose config to start-server and potentially support this via nrepl.config. That won't allow us to toggle dynamically the logging on/off, but it'd be a perfectly adequate solution for me.