[core-https][core-client] Core v2 cleanup work

[xirzec]

While preparing to talk about CoreV2, I found some small things to tidy up. This PR makes the following changes:

1. Remove keepAlivePolicy (Fixes [core-https] Remove keepAlivePolicy? #9587) - the use case is niche and you can still disable per-request.
2. Flip disableResponseDecompressionPolicy into a decompressResponsePolicy. This morally fixes [core-https] Move decompression into optional policy #9588, but I wasn't able to extract the actual decompression code from nodeHttpsClient since it's too tightly tied into the download progress stuff and being able to get the raw text on the response.
3. Fix an issue where phases in the Pipeline can execute out of order (e.g. a policy that is afterPhase: "deserialize" but beforePolicy: "serializationPolicy" would make serialization happen after deserialization.) Now phases have to drain completely before we proceed.
4. Make ndJsonPolicy opt in by adding it to the pipeline in the client. Similarly, make redirects opt-out by removing the policy. We had a lot of pipeline switches that amounted to "add this policy or not", but since Pipelines make it easy to add/remove optional policies, we don't need to have explicit config for this anymore.
5. Remove request cloning. There wasn't a clear purpose for making requests clonable, since they're not treated as immutable in the pipeline.
6. Remove additionalInfo on requests and hide it from public surface in a WeakMap. The only reason I didn't do this before is because of cloning, but without cloning we can now hide a lot of internal gunk that only core-client cares about.

Overall, nothing earth shattering in this, just cleanup and a fairly simple bugfix.

[joheredi]

Are you setting info anywhere else? it looks like it will always be {}?

[xirzec]

We assign properties to this object in serviceClient.ts lines 153 and 154.

[joheredi]

Looks good!

[bterlson]

I think we should ensure storage's usage of clone in its retry policy can be implemented reasonably without clone. ISTM that it would be pretty straight forward to store the primary URI in a variable even, as you might only need the map when other policies need to access your policy's request metadata?

[jeremymeng]

Storage clone the request because their retry changes the url/query parameters
https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/storage/storage-blob/src/policies/StorageRetryPolicy.ts#L162-L181

[bterlson]

I talked to @JeffreyRichter about mutable requests some and there is some potential for problems, although theoretical in nature - with mutable requests and retries, it becomes possible for a policy to see a request it has already seen before, and that has been mutated by downstream policies. Policies may have to code defensively against this if needed. E.g. a policy which destructively mutates the request body e.g. to encrypt it will still likely need to clone the request. With metadata being stored in weakmaps, the cloned request won't carry the same metadata.

I am not aware of any policies that would break with mutable requests, and it seems worth avoiding so many allocations, but it bears some pondering.

[xirzec]

Storage clone the request because their retry changes the url/query parameters
https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/storage/storage-blob/src/policies/StorageRetryPolicy.ts#L162-L181

Looks like the query params are set regardless of retry, just based on passed-in options. The host toggling seems to happen in sequence and not parallel, so it seems like you could solve this with a simple while loop that swapped the URL back and forth?

[bterlson]

Looks like the query params are set regardless of retry, just based on passed-in options. The host toggling seems to happen in sequence and not parallel, so it seems like you could solve this with a simple while loop that swapped the URL back and forth?

FWIW it looks like that to me too.

[xirzec]

After some more discussion, I think we can take this for now (based on what we need out of the pipeline today), but we should keep an eye on if a scenario for cloning exists in the future.