fix(oas): user data + server variable quirks

[kanadgupta]

🚥 Resolves RM-9110

🧰 Changes

This PR fixes two interwoven issues related to construction of server variable data.

Issue 1: User Data Payload Retrieval

If a user data payload has a keys array, our oas.defaultVariables() function will look in there but fail to properly retrieve any data from the top level of that payload.

For example, take the following the server variables definition:

{
  "url": "https://{name}.example.com:{port}/{basePath}",
  "variables": {
    "name": { "default": "demo" },
    "port": { "default": "443" },
    "basePath": { "default": "v2" }
  }
}

And say the user payload looks like this:

{
  "name": "owlbert",
  "keys": [
    {
      "apiKey": "test1"
    }
  ],
  "port": "8000"
}

Because of a quirk in our getUserVariable helper, the presence of that keys array in the user data prevents us from using that top-level data at all. The resulting URL is https://demo.example.com:443/v2 when it should be https://owlbert.example.com:8000/v2.

This was a one-liner fix in https://github.com/readmeio/oas/commit/6e89c4763b836919711b6f8138b13cae93b2487b and I also added some test coverage in https://github.com/readmeio/oas/pull/848/commits/366ffedb63c8588c6166b0a44af5b88f67b95455 😌

Issue 2: Server Variable Data Precedence in oas.url()

Quick background

Once I figured out the solution to issue 1 above, I noticed the following bug — when you're logged in and you have user data populating your server variables, editing the server variables won't update the code sample:

https://github.com/readmeio/oas/assets/8854718/5b9df9ce-377e-4d41-91ee-f90c2910fc35

Isolating the issue

After going down a crazy rabbit hole, I discovered the root issue was with how we use oas.url() to construct the URL in the auto-generated code snippet in our reference section.

For starters, we call oas-to-snippet to generate the snippet, which then invokes oas-to-har:

https://github.com/readmeio/oas/blob/77ba97d9edc06c20d366e4af358738fab8940fa0/packages/oas-to-snippet/src/index.ts#L81

Once we're in oas-to-har, we invoke oas.url() to construct the resulting URL:

https://github.com/readmeio/oas/blob/77ba97d9edc06c20d366e4af358738fab8940fa0/packages/oas-to-har/src/index.ts#L277

The issue itself

There are essentially three sources for these variable values that we need to deal with (in order of lowest to highest precedence):

1. Default values, as defined in the OpenAPI definition itself
2. User data, as defined via JWT
3. Current state data, a.k.a. whatever the end user manually writes into their API reference section

The problem is we were prioritizing 2 over 3. This PR reworks some logic related to oas.url() to fix that, see https://github.com/readmeio/oas/pull/848/commits/9fbea61e3eac19a2c5c52ae0207c7e8534162064 😮‍💨

🧬 QA & Testing

For all of this, the new test cases provide a great visualization of the changes and expected behaviors. That and all the existing test coverage passes, so hopefully we should be in good shape!