Fix multiline secret redaction when output with \r\n

[DrJosh9000]

Description

Make the string replacer engine match \r as part of \n.

Context

https://coda.io/d/Escalations-Feedback_dHnUHNps1YO/Pipelines-In-Progress-Board_suIFKYEb#Escalations-Pipelines_tuQbCBf6/r774&view=modal

Changes

• Partial matches now track string position and matched byte count separately. This is because, if \r\n is treated as a variation of \n, the number of matched bytes will be off by the number of \r bytes that were swallowed.
• Special-case the byte comparison when the needle byte is \n and the incoming byte doesn't match the needle byte. If the incoming byte is \r in this case, then keep the partial match for the next byte but don't increment the position in the needle (so the next byte to match should be \n, but could be another \r).
• Add a test.

Testing

• Tests have run locally (with go test ./...). Buildkite employees may check this if the pipeline has run automatically.
• Code is formatted (with go fmt ./...)
• Manually tested a build with an environment hook that adds a multiline secret and a pipeline that runs printenv.

[moskyb]

this LGTM, with the caveat: do we need to match \r+\n, or would it be okay to only match \r\n? is sequences of multiple carriage returns and then a newline a common thing?

i'm perfectly happy for that to be the case, but it might be worth writing a test for it, just to show that it's intended behaviour?

[DrJosh9000]

When looking at some raw logs with xxd, it often has 0d0d0a (\r\r\n) at line breaks, and I'm not really sure exactly where the double-up is coming from. So yeah, maybe it should be \r\n or \r{1,2}\n.