FQM-428: Create 2.2 Payer Suite Skeleton

[Jammjammjamm]

Summary

This branch contains a basic skeleton of what the completed 2.2 payer suite will look like.

Testing Guidance

A placeholder test to perform validation on the $questionnaire-package response was added, which may fail, but otherwise the actual tests in the suite haven't changed, they've just been reorganized, so there shouldn't be any changes to the current client simulation.

Anticipated Provider-side Test Impact

@karlnaden I'd be interested in any feedback regarding how/whether this organization will impact running against the client suite.

[karlnaden]

Two small things to think about. I think at a high-level this will work.

[karlnaden]

On the client side, we likely need to test the log error with $questionnaire-package (and maybe $next-question) - e.g., the client sends a $questionnaire-package request, the payer sends something specific back that triggers the error, so I think it may be worth having the option for Inferno to send the full set of interactions before the $log-... operation. Maybe it could be an option, but not a requirement?

[Jammjammjamm]

We could also put this in the big group with the other operations, or do you expect it to need to be standalone to use with the client suite?

[karlnaden]

I expect in the client suite that there will be scenarios where it:

1. waits for a $questionnaire-package request (and maybe $next-question)
2. returns something that should trigger an error
3. continues waiting for a $log-... request that indicates that the client determined there was an error.

For running against the server suite, we'd need a simulation that performs steps 1 and 3 and be able to have it execute them in a sequence. I think most designs for the payer tests will work:

1. If $q-p and $log-... are in separate groups, we'd have the client wait and run the two server suite groups in sequence.
2. If the payer suite's main $q-p group has an option to tell it to send a $log-... request, we'd have the client wait and use that option
3. If the payer suite's $log-... group has the option of doing the $q-p interaction before sending the $log-... request, then we'd have the client wait and run that group.

From the perspective of running the client suite against the payer suite, I like the 3rd option best because it keeps those scenarios separate so that we're not having to re-run the same group again or create a new server session to test the log error scenario. That said, if that doesn't work with your design of the payer tests, then I'm confident we can work around it.

[Jammjammjamm]

I think the 3rd option will work fine, so I can go with that.