Use paths security

[jonthegeek]

The paths object (as of my latest commit in local tibblify) can include a security field for each operation. The field contains a named list of security schemes for this operation (or possibly a character vector in some cases, need to check). We should use the name(s) to choose a valid security scheme. Scopes (sometimes present as the components of the list) are really only needed for documentation, although it might be nice to eventually make a function to build the auth request based on what you want to do (so try to figure out that ticket while working on this).

Operation-level security overrides global security, so, when this is present, any globally allowed scheme is not allowed for this operation.

We should build auth functions based on names of schemes in components@security_schemes, and then include calls to those functions in operation functions. Always allow the user to override calls, in case they want to provide a non-standard key, etc.

[jonthegeek]

Note: For Slack, there's effectively a single security scheme, but each path specifies which scopes it needs.

This is useful in an actual call if the auth happens at the same time as the function (duh, I should have realized that above; I'm too used to refresh tokens and such), but, barring live oauth, the scheme is identical.

[jonthegeek]

The operation function should take args that are needed by its security options (some/all of which might be optional; eg you might pass a bearer token, a refresh token, or neither, and then the function would have to interactively auth). Provided args pass on to valid security function. So security function doesn't have to be exposed to user, but has to be provided by operation function (when defined) and then passed on to caller. If operation function doesn't have a specific security definition, caller function will use a global default.

Edit: I talked about a scopes arg before but that's constant for a given operation; the user shouldn't have to know about it other than maybe to know to request it, but that detail can/should be hidden from most users, and just available via a request of some type.

Be explicit about arg names (stop using just "token"!) so it's clear to the user what we're expecting them to provide. Although I guess some might come from security scheme definition (eg apiKey schemes name their token).

So a given operation function might have:

• Auth-related args from the global/default security (but these would be ignored/deleted if the one below is defined).
• Auth-related args from its own security.
• Auth-related args specified as parameters because specs are often dumb. These need to be spotted and deleted. We handle this right now, I'm somewhat surprised to see!