Consider sanitizing all known secret values in text when serializing recordings

[heaths]

Currently we rely on known secret variable names or JSONPath to denote secret values in test recordings. For example, anywhere a variable named "MySecret" is used would be sanitized, or - after spending the compute to deserialize a JSON payload (if JSON; XML not supported currently) - a property matching some JSONPath should be sanitized.

But where secret values exist in text, relying only on JSONPath still requires a developer to input this and is prone to mistakes. While JSONPath also solves problems where secrets are output from services and not known at dev time (i.e. we need to keep support), I think it's worth considering something similar to what I did in Search: https://github.com/Azure/azure-sdk-for-net/blob/71054d50e35c7ebf5eee0a185c48dab702f6fb82/sdk/search/Azure.Search.Documents/tests/Utilities/SearchRecordedTestSanitizer.cs#L93-L125

Effectively, using both an as-is copy and JSON-encoded copy of the secret value search all text matching this value when saving a recording and sanitizing it. Because this could be expensive by default, we could still have developers opt into it, but wouldn't need to know all possible JSONPaths up front (and mitigates the case where the service may add some different patterns).

[heaths]

On a related note, @JoshLove-msft also suggested a great idea that could benefit any language by somehow hooking up CredScan to run on recordings using the test proxy.

/cc @pakrym

[weshaggard]

I pointed @scbedd to the CredScan as a library and I believe he has an issue tracking that for investigation.

[kurtzeborn]

@scbedd, pretty sure you already have an issue tracking this. If I'm right, go ahead and link to it here and close this one. We only need one issue to track work.

[scbedd]

Yeah, duplicate of #1950. Closing this one.