Compact WS data

[mcspr]

For #1367

Do not duplicate keys for relay, sensor, schedule, rfbridge, thingspeak & domoticz ws objects
Convert bool -> int (3 and 4 char shorter!) for status arrays
Minor edit _magnitudes.size() -> magnitudeCount()
Reuse single JsonObject for all callbacks

[mcspr]

I was distracted while doing the first merge.

Quick testing 4d5c0d7 with Windows / Chrome and 16 switch rfbridge. Compared to this, it takes full 1-2 seconds for all of the rfb messages to come through.
*edit: * In theory tcp layer would pack the data without nodelay set, but this does not happen somehow (or it is set somewhere). Need to check espasynctcp again...
edit2: tcp part is right here. next thing to try is to make websocket code write but not send immediately. ws is framed so browser will figure it out. Will update #1300 if this works

Also, notable comment from here: Links2004/arduinoWebSockets#187 (comment)

the 200ms from windows can be workaround-ed when you send a small answer at the moment when you get first message in the browser.
when you send data back from windows to the ESP windows will send the ACK immediately ;)

(which was referenced in #1300 by replacing module init code to send messages to the esp asking for each config part)

[mcspr]

Will force-push dev...mcspr:ws/optimize here to avoid doing merge + reduced buffer growth when using ws

Tangentially, this also lead up to trying to fix ws logging for the latest ESPAsyncWebServer by manually queueing messages. I wouldn't call it finished, as that approach only matters for ws. Telnet blows up with large payloads when using buffer and probably needs queuing like asyncwebsocket does internally. And it does not handle special case for '\r' char yet (OTA updates progress will fill the buffer with garbage)

ws/optimize branch now has an actually working buffered logger, but that still needs update to avoid duplicating messages when timestamping.

[mcspr]

I would argue that logging changes are related, but they can be split into a separate pr with ESPAsyncTCP / ESPAsyncWebServer versions update and general clean-up (like '\r' chars sent to ws when doing OTA and changes from ws/optimize to use application-level buffer for all the logging)

Also, missing rfm69 wsOnSend.

[mcspr]

@xoseperez Generally, if you do not like approach at packing everything inside single ws message, there are two solutions for the ack problem at hand:

• force webui to keep state of which cfg it loaded, sending something like {action: "load_cfg", {module: "relay"}} per each module and receive response from the esp. that way, only single module data is in the memory at once and queue is not kept filled. each time client responds with "action", ack is piggybacked inside, so the last message is removed from the queue whenever app yields into the system
• fork espasyncwebserver 🤷‍♂️ and introduce additional user callback that is called when tcp ACK is really received (and not guess with delay()). this will also help the solution from Print each HA config entry separately #1535 by making printer decisively send the data