This PR breaks out of the loop in NextReader after processing control frames.

NextReader returns noframe, nil, nil for PING and PONG messages. Because ReadMessage and ReadJSON expect a non-nil reader on success, those functions will panic on a control message.

The PR does not handle the case where data remains in the bufio.Reader. If two messages were slurped up in to the bufio.Reader, the second message will not be handled until a third messages is received. The third message will not be received until the fourth message and so on.

Given the above, the feature should be implemented something like this:

if c.allowReadControlMessages  && c.bf.Len() == 0 {
     return noframe, nil, ErrNoData
}

where ErrNoData is a new exported error value.

AllowReadControlMessages is not a good name for the public API. Control messages are always allowed. The name should somehow indicate that the feature is about returning from NextReader on no data.

The function that enables the feature should take a bool argument so that the application can turn the feature on and off.

A read buffer pool is the next obvious change for the non-blocking scenario. Any PR to support the non-blocking scenario should be a complete solution. We should avoid littering the API with partial attempts at fixing the problem.

There is active discussion on non-blocking read in the standard library. The standard library solution for non-blocking read may have an impact on how the feature is exposed here. If network connections invoke a callback when data is ready, this package should probably do the same. On the other hand, nothing has happened in the five years since the issue was opened.

This PR is missing tests. All features should have a test. Hold off on that until the other issues are addressed.