fix: Multipart delimiter boundary parsing

[calvincestari]

Fixes https://github.com/apollographql/apollo-ios/issues/3453.

The multipart message parsing code was not splitting message chunks at the correct boundary. It would only look for the dash boundary (--graphql) instead of the full delimiter (\r\n--graphql). This meant that if the dash boundary was present in the message body the chunk would be split causing a parsing error.

• Multipart delimiter changed to match the RFC specifications.
• Refactored property and function names to match multipart RFC terminology.
• Test data updated to represent RFC specification-matching message data.
• URLSessionClientTests restyled and new tests added to ensure correct delimiter parsing.
• Tests added to defer and subscription protocol parsers to ensure correct delimiter parsing.
• I've also done manual integration testing with the client-router-e2e-tests repo test services and everything works as expected.

[svc-apollo-docs]

✅ Docs Preview Ready

No new or changed pages found.

[netlify[bot]]

✅ Deploy Preview for eclectic-pie-88a2ba canceled.

Name	Link
🔨 Latest commit	010f5f4953193467ca9ddc3786e6f623779a3160
🔍 Latest deploy log	https://app.netlify.com/sites/eclectic-pie-88a2ba/deploys/67004a3ef2e6e900085ff50f

[netlify[bot]]

✅ Deploy Preview for apollo-ios-docc canceled.

Name	Link
🔨 Latest commit	010f5f4953193467ca9ddc3786e6f623779a3160
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-ios-docc/deploys/67004a3edabae100087061da

[calvincestari]

This LGTM! Is there any need to test when the body content inadvertently has something that looks like a multipart boundary somewhere in the text of the JSON?

Yes, that's what the tests I mentioned above do. Note that there are no tests for body data that contains the dash-boundary preceded, nor followed, by \r\n because that is explicitly not allowed in RFC2046. If that combination did appear in a message body it would be a malformed mulitpart chunk.