Support fallback stubs when proxy origin server down

[bbyars]

We have a new requirement to combine the proxy and stub modes in MB.

Currently we need to switch between proxy and stub modes when the downstream system is unavailable.

This is creating lot of manual efforts as the environment is unstable. So we need MB to respond from a static or prerecorded set of data when proxied response has an http status code 500(internal server error). Have to add an assertion on the response from server and route to stubbed response without switching to stub mode explicitly.

Appreciate your support and let me know if any other details are required.

[bbyars]

Also requested at https://groups.google.com/forum/#!msg/mountebank-discuss/hQa6Mf1Y53M/0CLn5tXuCwAJ;context-place=msg/mountebank-discuss/mYb636LwyP4/4Yim9KOaBwAJ

[bbyars]

Initial thought is an interface that looks something like this:

"stubs": [
  {
    "responses": [{
      "proxy": {
        "to": "http://origin-server.com",
        "mode": "proxyOnce",
        "predicateGenerators": [{ "matches": { "path": true } }],
        "failedConnectResponse": {
          "statusCode": 500
        }
      }
    }],
    "_behaviors": {
      "ignoreIf": {
        "startsWith": {
           "statusCode": 5
        }
      }
    }
  },
  {
    "responses": [{
      "is": { ... }
    }]
  }
]

That provides a general purpose (multi-protocol) approach that I think works in all cases, and involves two new fields:

• failedConnectResponse - The response if the proxy cannot connect to the origin server. Leave existing behavior in place if this is missing.
• ignoreIf behavior - The stub should be skipped if the response matches the predicates (using the same format as request predicates).

failedConnectResponse should be easy to add. ignoreIf is considerably more difficult. The following should be true if we're ignoring the stub response:

• The next response should not change. The user can pass in an array of responses that cycle on predicate matches. By the time we realize that the selected response should be ignored, we would have already changed the state inside stubRepository to move that response to the end of the cycle. That should be reset
• If there's also a repeat behavior, and the response is ignored, we need to make sure that the response doesn't count as one of the repeats. I believe, once the bullet point above is solved, this will also be solved
• ignoreIf should be the first behavior checked for performance reasons. If we're ignoring the response, no further transformations should take place
• We should not add to the requests or matches arrays (with the --mock or --debug CLI flags) if we're ignoring the response for that stub.