Optimize reading RPC responses

[ZmnSCPxj]

In #13 it seems ChannelFinderByPopularity takes a lot of CPU processing, which causes issues with responsiveness, since CLBOSS also hooks on rpc_command.

#15 would help reduce reduce processing load after the listnodes command returns, but the time from listnodes out to listnodes in is also pretty big, and is probably an even tighter processing load (ChannelFinderByPopularity performs Ev::yield after listnodes returns, but Boss::Mod::Rpc does not explicitly yield while processing the listnodes command).

2020-11-05T05:26:49.503Z DEBUG   plugin-clboss: Rpc out: listnodes {}
...
2020-11-05T05:45:48.127Z DEBUG   plugin-clboss: Rpc in: listnodes {} => {\n\t\"nodes\" : [\n\t\t{\n\t\t\t\"nodeid\" : \"0326efa5d368844e2c9cf1e46891a5d40cc5dc9d2371cfa23968d1fdf61b64814d\",\n\t\t\t\"alias\" : \"0326efa5d368844e2c9c\",\n\t\t\t\"color\" : \"3399ff...

That is ~19 minutes. True, this is on a lightningd running under valgrind but nonetheless, we should probably optimize it better.

Currently we feed 256-byte chunks of data to the parser. We can increase the chunk size (4096 seems better overall, at least for Linux).

Or, we could do what C-Lightning builtin plugins already do, which is to keep putting bytes in a buffer until it reaches a \n\n (two newline chars) and only then sending it to the parser. C-Lightning has a quirk where it emits two newline chars in succession at the end of each entire JSON datum. The JSMN parser is fast if and only if you give it an entire JSON datum, giving it a partial datum means it has to keep restarting the whole parse sequence from the start of the datum.

Unfortunately this ties us to a particular quirk of C-Lightning, meaning that if people use wrappers and so on (e.g. run clboss on one system while running C-Lightning on another) the quirk also has to be replicated.

Perhaps an alternative that does not tie us to this quirk of C-Lightning would be to keep putting bytes in a buffer until the socket would block on read, and then send to the parser, and explicitly yield at that point.

Yet another possibility: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#WATCHER_PRIORITY_MODELS

[ZmnSCPxj]

In addition to moving parsing of RPC responses into an idle watcher, I also had rpc_command specially handled by the stdin processor, which should help responsiveness when CLBOSS is busy.