fix issue leading to slowdown/unbounded memory growth in binary json processing

[tomqext]

Public API Changes
None

Description

When a WebSocket client sends JSON as binary frames (ros-sharp does this), onMessage in the autobahn handler only decodes text frames - binary frames get pushed to the IncomingQueue as raw bytes. In Protocol.incoming(), the buffer concatenation does self.buffer = self.buffer + str(message_string), which in Python 3 produces the repr rather than decoding:

>>> str(b'{"topic":"foo"}')
"b'{\"topic\":\"foo\"}'"

This isn't valid JSON (leading b'), so json.loads() fails on every message and falls through to the bracket-scanning fallback (designed for reassembling partial TCP fragments). That fallback iterates over every {/} pair trying json.loads() on each substring - O(n²) in the number of brackets. It does eventually find the JSON inside the garbage, so everything worked, just very slowly.

In our case we were publishing 52-transform messages at 50Hz from ros-sharp (~322 bracket pairs per message). The fallback took ~48ms per message vs ~2.6ms for the actual deserialization + publish. The consumer thread couldn't keep up, so the IncomingQueue (unbounded deque) grew without bound - memory climbed indefinitely and data fell further and further behind real-time as the session progressed.

The fix decodes bytes before buffering instead of calling str(). The bracket-scanning fallback is still there for TCP fragmentation, it just stops being the hot path for every binary WebSocket message.

Most rosbridge clients (roslibjs, roslibpy, C++ clients) send text frames so they never hit this - the str() call is a no-op on an already-decoded string. ros-sharp is the main client that sends binary frames which is why this went undetected

[bjsowa]

Is this only related to the ros1 branch?