[Unified recorder] String sanitizer support + sanitizer refactor

[timovv]

Checklists

• Added impacted package name to the issue description

Packages impacted by this PR:

• @azure-tools/test-recorder

Issues associated with this PR:

• [Recorder] Support the string sanitizers #19809
• [Unified Recorder] Option to add session level sanitizer #18223

Describe the problem that is addressed by this PR:

The main motivation of this PR was to add support for the new string sanitizers introduced in Azure/azure-sdk-tools#2530. As part of this, I've also tackled some refactoring that will be required for session-level sanitizer support (#18223) where we will be wanting to enable adding sanitizers without access to an instance of the Recorder class. While implementing the new sanitizer logic, I refactored the addSanitizers method into smaller chunks to make adding additional sanitizers easier. To summarize the changes:

• Removed the Sanitizer class, instead making the addSanitizers function in sanitizer.ts take in a HttpClient and recording ID as parameter.
• Refactored the addSanitizers function to call smaller functions for each sanitizer (some of which are a bit FP-style) instead of using if statements + special cases. Hopefully this will make things a bit easier to maintain.
• Some other minor refactors (e.g. extracting duplicated createRecordingRequest function into a utility).
• Add support for the string sanitizers in what I think is the most logical way, but there is a breaking change:
  • When calling addSanitizers, instead of specifying generalRegexSanitizers: [...] etc., you now specify generalSanitizers: [...]. Both regex sanitizers and string sanitizers can be used in this way, for example:

recorder.addSanitizers({
 generalSanitizers: [
   {
     regex: true, // Regex matching is enabled by setting the 'regex' option to true.
     target: ".*regex",
     value: "sanitized",
   },
   {
     // Note that `regex` defaults to false and doesn't need to be specified when working with bare strings.
     // In my experience, this is the most common scenario anyway.
     target: "Not a regex",
     value: "sanitized",
   }
 ],
});

I think it's more logical grouping GeneralRegexSanitizer and GeneralStringSanitizer into one option in addSanitizers since they are so similar in effect (the only difference is whether or not the target is a regex). I think it's worth the breaking change at this early stage, but if others disagree, we can keep the current API, adding a generalStringSanitizers: entry to the sanitizer options.

I use generalSanitizer in the above example, but it's worth noting that this change applies to all the sanitizers that follow a similar pattern (e.g. BodyRegexSanitizer and BodyStringSanitizer).

[check-enforcer]

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run js - [service] - ci

[HarshaNalluru]

Looks great overall 🎉

[sadasant]

All things considered, if CI passes and Harsha approves, this PR is good to go in my opinion.

[HarshaNalluru]

Lesssssgo! ✅