fix(recorder): escape single quotes in path of default output (nock#2137

)

Because the default output of the recorder uses single quotes, any such
quotes in the path would generate invalid Javascript.

fix(intercept): handle global flags during regexp matching (nock#2135)

When matching via a regexp instance, consistently test the entire target string.
Sets the `lastIndex` to zero for cases where the `global` flag is set and the
regexp instance has been tested previously.

fixes: nock#2134

fix(overrider): allow calling empty `req.end` multiple times

Node source showing this is expected behavior:
https://github.com/nodejs/node/blob/39a7f7663e8f70fc774105d8fa41b8e4cc69149f/lib/_http_outgoing.js#L816

Two tests were added, one for the regression itself, and one to fix coverage
for a block that lost coverage when the bug was patched.

fix: Parallel requests on same Interceptor are exposed correctly in r…

…eply functions (nock#2056)

Fixes regression created in nock#2033.
Reply functions get access to the current request via the Interceptor,
which acts as the context during the function executions.
The previous change, incorrectly moved the line where the request was attached
to the Interceptor up in the flow and out of the same microtask that calls the
reply functions. Causing requests in parallel to lose the reference to the correct request.

fix: data comparison with undefined object values (nock#2049)

Updates the `dataEqual` utility and underlying `deepEqual` recursive functions to treat explicit and implicit `undefined` object values as equal.
Also ensures that `expand` is only called on top-level data if they're plain objects, thus avoiding accidentally equating an object and an array if the object's keys happen to be integers.

fix(intercept): mark Interceptors consumed immediately (nock#2033)

When an request is matched to an Interceptor, mark it consumed immediately so
that similar requests made in parallel don't get matched incorrectly.

This changes the behavior of aborted requests slightly.
Previously, an Interceptor was marked consumed just prior to the "response" event.
Now it will be marked consumed just prior to the "finished" event.
The change can only be noticed if a request is aborted while in a "finished" listener.

fix: allow Content-Type request introspection when header is an array (…

…nock#2010)

* Gzipped request bodies also work when header is passed as an array (nock#2009)

Merge branch 'beta' into next

# Conflicts:
#	README.md

fix(ClientRequest): Use native `abort` and `destroy` (nock#2000)

- Stop monkey patching `abort` on the overridden `ClientRequest`.
- Stop prematurely associating the socket with the request.
- Prefer `destroy` instead of emitting an error when appropriate.

feat: remove socketDelay (nock#1974)

From a user's perspective, having both `delayConnection` and
`socketDelay` is confusing and unnecessarily.

The differences between the two are subtle, and in my experience, users
need to be fairly well versed in both the Node HTTP module and the
internals of Nock in order to accurately determine which to use.

On the surface there seems to be two use cases:
- A user wants to test how their code handles a `timeout` event.
  Whether their client is expected to abort the request, or some other
  action is taken in response to the event. Either way, the user
  doesn't care if wall-clock time passes, and would prefer the timeout
  be simulated so their test suite can get on with it.
- A user wants to force wall-clock time to pass before a `response` event.
  This is usually to test some timeout feature that is not based on the
  `timeout` event, or to give other code time to complete a task first.

Based on those two use cases, it seems obvious that there should be two
different delay functions, like we seem to have now. However, there are
two subtle aspects that blur the line.
- When a socket emits a `timeout` event, which the request propagates,
  the request does not end. This is true in Node and in Nock today.
  Clients my choose to abort a request upon a timeout event, they may not.
- In Nock today, when the socket is "applying" the artificial timeout,
  to determine if it should emit a `timeout`, it doesn't just use the
  value passed to `socketDelay`. It uses the sum of the values passed
  to `delayConnection` and `socketDelay`. This covers the flow of a
  user wanting to ensure their code sees a `timeout` event even if no
  action is taken.

Therefore, there is no reason to have two different options for users.
The value passed to `delayConnection` can trigger a `timeout` event
right away and if the code chooses not to act on the event, then it
will wait in real time until `response` is triggered.

In fact, when I began working on this, I went into the
`test_socket_delay.js` file and replaced all `socketDelay` with
`delayConnection`. All the tests passed.

Other minor tweaks included in this change:
- The delay methods on the Interceptor are now just setters instead
  of additive. This was undocumented, unintuitive behavior.
- Fixed a bug from nock#1973, where `replayWithError` would cause
  Interceptors to be consumed twice.

BREAKING CHANGE:

- `socketDelay` has been removed. Use `delayConnection` instead.
- `delay`, `delayConnection`, and `delayBody` are now setters instead of additive.
  example:

```js
nock('https://example.com')
  .get('/')
  .delay(1)
  .delay({ head: 2, body: 3 })
  .delayConnection(4)
  .delayBody(5)
  .delayBody(6)
  .reply()
```

Previously, the connection would have been delayed by 7 and the body delayed by 14.
Now, the connection will be delayed by 4 and the body delayed by 6.