Set appropriate Accept header for Search clients

[heaths]

Fixes #11532

[heaths]

@pakrym I had to switch the order of sanitizing variables and content so that we can properly capture which variables need to be sanitized from content.

@tg-msft @brjohnstmsft I noticed from some of the test recordings that when we get a SearchIndexClient from a SearchServiceClient, we "inherit" its HttpPipeline which still uses the "minimal" Accept header. I can fix this but need to make a few small refactorings. But it made me wonder if other languages have the same problem, and noticed that Python and JS don't have a getIndexClient method.

• SearchServiceClient should expose a getSearchIndexClient azure-sdk-for-js#8525
• SearchServiceClient should expose a getSearchIndexClient azure-sdk-for-python#11041

I noticed that Java may have the same problem, too, since it passes the pipeline. /cc @sima-zhu @alzimmermsft

• SearchServiceClient should expose a getSearchIndexClient instead of getIndexClient azure-sdk-for-java#10491

[tg-msft]

Here's a transform that I think does what you're looking for:

Add Accept header

Return no metadata for /docs operations and minimal for the rest.

directive:
- from: swagger-document
  where: $.paths
  transform: >
    for (var path in $) {
      for (var opName in $[path]) {
        var op = $[path][opName];
        var accept = "application/json;odata.metadata=";
        accept += path.startsWith("/docs") ? "none" : "minimal";
        op.parameters.push({
          name: "Accept",
          "in": "header",
          required: true,
          type: "string",
          enum: [accept],
          "x-ms-parameter-location": "method"
        });
      }
    }
    return $;

[tg-msft]

Looks good!