Add test for frame spillover issue (#218, #230)

[hyperair]

When Frame.parser is given more data than expected, the next frame's header +
contents can end up as part of the payload, causing a UTF-8 validation error, or
ends up being thrown away. This can happen in the SSL case if we read slowly and
allow the socket's buffer to fill up a little.

This commit fixes that by amending WebSocket.once() to only provide bytes <=
reading_buffer_size to the stream parser and keeping the rest in a buffer,
giving the Frame a chance to stop receiving data at a frame boundary.

Fixes: #218

Edit: This PR now only contains tests for the issue since the issue itself has been fixed by #239.

[Ngo-The-Trung]

I think the assertion is contrived and can be removed (it's not validating anything outside the function's scope).

[Ngo-The-Trung]

@tito looking for your comments

[bytesofmyself]

Any ETA on this being merged?

[Ngo-The-Trung]

@bytesofmyself unfortunately it seems like this is not maintained until there's a new maintainer

[amiasato-zz]

Commenting on this PR to show some appreciation, because this was an issue which was affecting me pretty badly. Thanks a lot for the fix.

It would be nice if #222 would check on this as well.

[Serpens66]

I used veersion 0.3.4 a long time without any problems.
Then I thought it might be good to upgrade to 0.4.2 and did it... bad idea.. since then I'm missing alot of messages... unusable...
I downgraded and it is working fine again.

Is this pull request fixing this issue? Or is it another issue?
Should I stay with 0.3.4 version ? Or are there other bugs I did not discover yet?

[amiasato-zz]

@Serpens66 It is very likely if you are using SSL/TLS sockets, otherwise the only way of knowing is testing for yourself.

[hyperair]

This seems to have been superseded by #239. I've rebased onto master so that this PR only adds tests for the frame spillover issue now.