[vincent-richard]

A deeply nested multipart message could exhaust the stack, as each level of nesting recurses into body::parseImpl(), and the parsing time grew with the square of the nesting depth.

Stack exhaustion:

• Body parts are no longer split beyond a maximum nesting depth, which defaults to 100 and can be changed with parsingContext::setMaxNestingDepth(). A multipart part at this depth keeps its body contents as is, like a non-multipart part, so no data is lost.

Parsing time:

• component::parse() wrapped the input stream in a new parserInputStreamAdapter even if it already was one, so each level of nesting added indirections to all the stream accesses of the levels below it.

• The boundary search did not stop at the end of the enclosing part, and was run once more after the closing delimiter: each level scanned the rest of the message, up to the end of the stream.

• Each match rejected by findNextBoundaryPosition() (not at the beginning of a line, or prefix of another boundary) restarted a search which read 4 KiB ahead. The search is now for "\n--boundary", and parserInputStreamAdapter::findNext() starts with small reads, so that its cost depends on the distance to the match. With boundaries "a", "aa", "aaa", etc. nested 100 levels deep, parsing a 1 MiB message took 150 s.

parserInputStreamAdapter::findNext() takes an optional end position. It no longer searches the bytes of its buffer twice, nor returns wrong positions with streams which return fewer bytes than requested.

Behaviour change: the boundary of a multipart part is now only searched for within this part. If its closing delimiter is missing, its last part extends to the end of the enclosing part; before, it became epilog text if the boundary appeared again further in the message.

Fixes #366. Reported by @DrNbnonono.