[INS-1668] handle multiple security requirement objects

[filfreire]

Closes #INS-1668
Closes #4454

TL;DR: in the past we already added all the auth methods for the OR case, according to spec, but we didn’t handle the AND case because we just picked the first key out of a pair of Api Keys, for example.

Investigation

According to spec there is logic defined when handling multiple security requirement objects:

Security schemes combined via OR are alternatives – any one can be used in the given context. Security schemes combined via AND must be used simultaneously in the same request.

What this means in practices is, again, according to spec:

Here, the API requires a pair of API keys to be included in requests:

security:
  - apiKey1: []
    apiKey2: []

Here, we can use either OAuth 2 or a pair of API keys:

security:
  - oauth2: [scope1, scope2]
  - apiKey1: []
    apiKey2: []

The problem on Insomnia happened when we would define what by spec is a pair of security api keys to a given request, if we did it like this:

security:
    - apiKey: []
      appSecret:  []

Insomnia would (wrongly) consider the first part of the pair and ignore the rest, resulting in only one of the variables being generated when interpreting the OpenAPI spec:

Which caused the symptoms we see in #4454. This wasn't reproducible if we didn't define a pair by spec:

security:
    - apiKey: []
    - appSecret:  []

since each would get handled as an 'OR', and would translate into this on the App:

After this PR

Now both approaches translate into:

And we leave out to the user to afterwards disable and pick whichever api key or security scheme they want to use in a particular request.

changelog(OpenAPI-2-Kong): Fixed an issue where multiple security requirement objects, like pairs of API keys, were not properly handled when generating requests from an OpenAPI spec