RFC - Consistent path comparison

[mastermatt]

BREAKING CHANGE: The query/search portion of the path is now always excluding during path matching.

Previously, the pathname and search string were included during path comparison by default, however, the search string was removed during the matching step if the query method had been called or a search string was provided as part of a string to the first argument of a "verb" method.
This change makes the experience consistent by making query/search matching exclusively opt-in.

I find this little diagram useful, to clarify terminology.
https://nodejs.org/api/url.html#url-strings-and-url-objects

By example:

nock('https://example.com')
  .get('/foo')
  .reply(200, 'OK')

GET https://example.com/foo?name=alice
Previously, Nock would not have matched the request because the search portion of the path on the request did not match what was provided to Nock.

This change removes the search portion during that matching step and will now match the request.

If you're Nocking a request where matching the query/search portion is desirable, then using the .query() method or passing a search string as part of the path will continue to work as it did before. ei .get('/foo?name=alice') or .get('/foo').query({name: 'alice}) etc.

The noticeable breaking change will be those using a RegExp or callback function on the path.
.get(/foo.*alice/) nor .get(uri => uri.endsWith('alice') will work going forward as only "/foo" will be supplied to the match or callback.

Reasoning

It is believed that this behavior is more intuitive to consumers. The idea that the search parameters are considered a separate chunk of data on the request, similar to headers and the body. And therefore should follow the same pattern where Nock should match the request unless the caller opts-in to comparing the search params.

[mastermatt]

The most recent example of the current behavior causing confusion #2322
fyi @ebisbe