[tests]: postman environment keys not replaced with server variables

[MikeRalphson]

expected Object { url: '{{baseURL}}' } to have key variables
	missing keys: variables
#/info/servers/0

Occurs in gotomeeting.postman.json fixture.

[kevinswiber]

To support this, I'd like to first have a warnings mechanism. So, here's how this works... We parse the URLs using Postman's variable resolution algorithm (which is a tad more difficult than one may think), substituting Postman collection variables with the resolved values.

If a variable is unresolved, like in this case, we can detect that and create a variable entry under the server object. However, in server object variables, the default field is required, and there's no sensible value we can infer. We can put a dummy value there, but so far, the approach we've taken is to leave the un-resolvable conflicts be. This means users need to depend on a separate schema validators/linters (like boast!).

Is there a way this can be auto-resolved without breaking OpenAPI definition usage?

[MikeRalphson]

Agree, the possible combinations of templated variables probably make this an intractable problem, and that's just for servers.url, I'm unsure if Postman env. variables can be used only in specific places or absolutely everywhere.

It might be worth special-casing the situation where a URL becomes unresolved by (optionally?) removing it (or moving it to a specification extension x- property) but it's messy.

Part of the problem is that the double-bracket syntax looks like an OAS templated variable, when it's really not. Perhaps there is some other URL-friendly delimiter which could be used instead?

Again, agreed it might be better to leave this up to the application using the converter to support an environment map in some form if needed, either pre- or post- conversion.