We (1Password) encountered some users on Linux who were encountering issues using custom certificate roots on their devices, which had been added to the "main" system CA bundle. The root cause of the issue turned out to be rustls-pemfile only supporting UNIX newline endings in parsed files (\n). The certificate bundles sent to us by users though contained one or more PEM objects with \r endings interspersed with ones using \n.

This PR proposes fixing the incompatibility described above by switching to a more lenient line parser function. BufReader::read_until was insufficient for this purpose because it only supports looking for a single needle. Instead, I ported the implementation of read_until out of the standard library and slightly tweaked it to look for more characters. While this uses the more low-level BufReader functions, its been well-tested already and has correct error handling. Thanks to @Ralith for helping point me in the right direction.

Additionally, I believe this is technically more correct based on RFC 7468 (assuming this is the right one 😓) as they call out support for multiple line endings:

Furthermore, parsers SHOULD ignore whitespace and other non-
base64 characters and MUST handle different newline conventions.

A full regression test is included as well. It can be confirmed by undoing the changes to src/pemfile.rs and running cargo test. It should panic with a bogus error. The data file consists of the same Amazon root CA repeated 4 times, but with 2 LF and 2 \r objects.

AFAICT, the only downside of this change is that it has a performance impact, even if almost imperceptible:

A user would need to parse an absurd number of PEM objects to notice the difference, and the only no_std compatible way of regaining it is adding a dependency on the memchr crate, which does not seem to be worthwhile.