Revise parameter handling for snippets

[michaelgwelch]

This is a large PR, but each individual commit is small(ish). The test cases are what make some changes look large. Each commit addresses one (or two) issues at a time (usually).

This commit does several related things.

• consider examples for parameter values

  If example isn't set for a parameter, then go ahead and check for examples. If that is present, then use the value from the first entry as the parameter value.

  Fix #81

• implement support for explode for array and object

  Fix #83

• Fix 3 test scenarios that showed unexploded form parameters when explode should have default to true

  This was documented in #83

• Resolve $ref nodes for header parameters

  Fix #84

• Add a full suite of tests for parameters.

• Add support for cookie parameters

• Handle the merging of path and operation parameters correctly for all parameter types, not just query ones.

  Fix #85

• Add support for label and matrix style path parameters

• Add support for space and pipe delimited query parameters

• There is support for deepObject style, but the httpsnippet library encodes all the special chars so I don't know if that's correct or not.

• Resolve references in examples object as needed

[ErikWittern]

@michaelgwelch Hey, wow, it seems you put quite a lot of work into this PR, addressing multiple issues at once. Thank you very much!

You did open and then close again a few other PRs. So just to be on the same page: is this one ready-for-review from your point of view? Once it is, I will try to provide a review quickly, but might need a few days given other obligations. Just wanted to be upfront about this.

Thanks again, and let me know when I start reviewing.

[michaelgwelch]

You did open and then close again a few other PRs. So just to be on the same page: is this one ready-for-review from your point of view? Once it is, I will try to provide a review quickly, but might need a few days given other obligations. Just wanted to be upfront about this.

Hi @ErikWittern, yes I'm sorry for spamming your repo. When I submitted the first PR I quickly realized that this work was larger than I imagined. And I really wanted to submit a PR with smaller commits.

You can start to review this. I tried to stay faithful to your style and direction but realize I may have gone astray from how you would have liked. Let me know how I can help.

[michaelgwelch]

I think the most problematic issue is the test organization. I exposed an internal openapi-to-har function because there were so many combinations I would have had to have checked if I went thru the OpenAPISnippets interface. Perhaps those tests should go in their own module that test openapi-to-har directly. Then I don't need to export createHarParameterObject from that module.

The test descriptions may need more work as well?

[ErikWittern]

@michaelgwelch I finally had some time looking over your changes. I am extremely grateful, they look fantastic!

You point out some specific areas of interest related to testing. Here are my thoughts:

• Exposing createHarParameterObjects directly from openapi-to-har.js is, in my opinion, not a big issue, as they are not also exposed by index.js.
• The test descriptions are fine with me as well, given they follow a consistent structure and are designed to cover a broad range of cases

Once more, thank you so much for the contribution! I will create a new release based on these changes.

[michaelgwelch]

Very glad to hear you were able to work your way thru it all. On my project we've been running with these changes (from my fork) since I posted the PR back in May without issue. So I'm hopeful the tests have provided adequate coverage. Will be glad to switch over to the next released version and off of my fork.