Performance: Look deeper into scaling N+ contributors per pad.

We have scale.etherpad.org and etherpad-load-test as tooling to document & validate how many editors can be on a pad but I'm not sure we ever seriously dived deep into alternatives to get the numbers of editors on a pad beyond what is available on scale.etherpad.org

My thoughts are..

1. Transport layer IE try websocket over socketio
2. Node ENV vars IE allow more memory to node (afaik our bottleneck is Network IO tho).
3. Message reduction size IE providing a buffer within the changeset messages for when there are thousands of edits landing a second its not 1000 tiny packets but 100 larger ones...