Nio Parser fails on extra CRLF at the end of message body

[coderartem]

Run into issue with NioPipelineParser when processing SIP message with an extra CRLF at the end of message body received over TCP connection that stays alive forever.

Say SIP message has "Content-length" reported as 20000 and body that ends with double CLRF like:
messagebody\r\n\r\n

Only first \r character included in "Content-length" so we end up with \n\r\n characters at the end.
Parser switch back to message headers processing and read \n as line of new message headers then see \r\n and treat it as headers separator switching back to message body processing. Because it didn't read any "Content-length" in this new fake message Content-length stays at 20000
So now any subsequent message we receive on same TCP channel goes straight to body of that fake message until we accumulate enough bytes to meet 20000 Content-length mark. Then it switch back to headers processing and read tail of last message received as headers of another new fake message. And so on.

It is able to recover if at some point it read "Content-length" of one of subsequent messages that set to "0" while processing message headers.
But goes into this loop again on next message with extra CRLF at the end of body

From SIP RFC 3261 :

7.5 Framing SIP Messages

Implementations processing SIP messages over stream-oriented
transports MUST ignore any CRLF appearing before the start-line
[H4.1].
The Content-Length header field value is used to locate the end of
each SIP message in a stream. It will always be present when SIP
messages are sent over stream-oriented transports.

From HTTP/1.1 RFC 2616 referred in SIP RFC:

4 HTTP Message
4.1 Message Types

In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.