Provide an optional per-request active scenario override using a cookie

[tdrak-amex]

Change to parrot-core and parrot-middleware.

When resolving a request, use an optional method which will look for a parrot scenario name in the request cookie and use this to determine which set of mocks to use instead of using the active scenario.

Description

• Added logic to resolve in Parrot.js (parrot-core) that calls a new getActiveScenarioOverride method on the Parrot instance that will retrieve the active scenario override, or undefined. If this exists this is then used to select the set of mocks to match against, rather than the activeScenario instance variable.
• Added the 'cookie-parser' express middleware (parrot-middleware) to enable the cookie to be parsed from the request later on.
• Implemented the getActiveScenarioOverride method in the ParrotMiddleware implementation of Parrot (parrot-middleware). This looks for a cookie with the name parrotScenarioOverride and returns this value, or undefined.
• Added a new jest-when package as a dev dependency (parrot-core). This allowed for the thorough testing of the parrotTest.resolve method but in a concise way. jest-when allows you to set return values for specific function call parameters - thereby effectively asserting on the the inputs values at the same time as providing mocked responses.

Motivation and Context

We have recently undertaken some work to allow Browser Tests (webdriver.io / selenium) to run in parallel. But these tests were limited by the fact that the mocking framework that they used (parrot) did not support more than one active scenario at a time. This enhancement will allow for tests to set the parrot scenario that they need per-test using a cookie set on the browser session - thereby enabling these tests to safely run in parallel with different mocking requirements.

How Has This Been Tested?

In addition to the new unit test coverage added to both parrot-core and parrot-middleware, this was also manually tested from a browser & by running a browser-test suite (webdriver), both locally and on CI. It was tested that the active scenario functioned as before, via a post to the server. It tested that it was now possible to select the active scenario for a request via the cookie. It was tested that two separate browser sessions could set different active scenario overrides at the same time.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (adding or updating documentation)
• Dependency update

Checklist:

• My change requires a change to the documentation and I have updated the documentation accordingly.
• My changes are in sync with the code style of this project.
• There aren't any other open Pull Requests for the same issue/update.
• These changes should be applied to a maintenance branch.
• This change requires cross browser checks.
• This change impacts caching for client browsers.
• I have added the Apache 2.0 license header to any new files created.

What is the Impact to Developers Using parrot?

There should be no impact as this is an optional feature. But the benefit will be that they are now able to set the active scenario per-request if required.