Add packet transfer protocol

[rikkuness]

Will keep this open as a WIP and add to it as I work things out to make sure I don't end up too far down a wrong path.

Fixes #187

[gfwilliams]

Looks good so far! I think given EventEmitter isn't on browser it might be worth adding .on/etc to Espruino.Core.Serial in the basic way done at https://github.com/espruino/EspruinoWebTools/blob/master/uart.js#L401-L409 - then add the packet parsing stuff (https://github.com/espruino/EspruinoWebTools/blob/master/uart.js#L437-L471) in where we do XON/XOFF https://github.com/espruino/EspruinoTools/blob/master/core/serial.js#L222 ?

I guess the input data handler would ideally be its own function rather than buried inside openSerialInternal?

Right now we don't remove XON/XOFF chars from the input stream, but I think we'd probably want to do that now (as we need to be able to remove the packet ACK/NAK anyway) - and to reliably receive binary data I think we need to ignore XON/XOFF when in the middle of receiving a binary packet.

[rikkuness]

Yeah missing the events stuff was catching me out, and by first stab at writing the packet parsing I did using Buffer before realising that's also not in browser 😂

The ACK/NACK does that come right after the write, so there's no control chars or anything as a preamble? Just that window of within a second after a write expect a 6 or 21 char?

Another thing I wasn't sure on after reading more about the protocol (and I've not dug too much into the C code yet), with something like a FILE_RECV you expect to get back n packets and then completing on getting back a packet with 0 in the length? How about for an EVAL? If I for example ran an eval that listed the contents of the filesystem which wouldn't fit in an 8191 byte frame, do you get multiple RESPONSE packets, or do you just have the limitation of that size of response?

[gfwilliams]

Yeah, it's a pain not being able to rely on certain things being built in (atob/Buffer/etc) - EspruinoTools/WebIDE feels a bit hacky but really I've just been trying to get something as simple as possible with as little dependencies as I can (and not relying on transpiling so you can self-host/debug easily).

Just that window of within a second after a write expect a 6 or 21 char?

Correct, yes.

...wouldn't fit in an 8191 byte frame, do you get multiple RESPONSE packets, or do you just have the limitation of that size of response?

There's just a limitiation of response size (it's just one packet). Not ideal, but it's simple.

One thing to note is the response is produced by E.toJS so you get stuff like {a:1,b:2} which is more compact, but which JSON.parse won't touch - it's why we have parseRJSON