Add connector config to oauth api

[ChristopheDuong]

What

New OAuth flows will need values from the connector config in #6971

How

Alteernative to #7798

This API changes adds an "optional" connector config parameter to the API endpoint:

• if config is provided, then we can follow the new oauth specification and implement OAuth flow: Refer to AuthSpecification config to format outputs with correct oauth response structure #7216 where values will be seeded into the connector config after completing the oauth flow. The API will return a valid connector config with oauth values already injected.
• if config is not provided, then previous behavior is kept

Context

• When FE calls the completeOauth API endpoint, a partial connectionConfig (that the user is trying to create, as if it was the SourceCreate API but not exhaustive yet) can be passed.
• If any fields is used as input fields to the oauth flow, the backend can refer to these values directly in the connectionConfig.
• once oauth flow is completed, the backend will copy the oauth outputs back inside the connector config where it needs to (in the rootObject) along with placeholder masked instance-wide params and return the modified connectionConfig. The merge of connectionConfig + oauth outputs is therefore not needed in the front end anymore.
• so after that call the FE can just forward the new connectionConfig to SourceCreate when clicking on "setup connection"

[ChristopheDuong]

I would expect this requires some small tweak to do in the front-end code to keep it compatible with the API change?
(the completeOauthResponse is now nested under oauthOutput)

cc @jamakase

[sherifnada]

How come we are passing in connectionConfiguration and not an oauth specific configuration like we discussed in the spec?

[ChristopheDuong]

if we pass the connectionConfiguration (which includes the authConfiguraton as a child node btw)

The backend can do the "seeding" to the connectionConfiguration and return the modified config back to the frontend.

We can also go read the "input" fields such as shop_id directly in the connectionConfiguration.connectorSpecification which would be a "partial" connectionConfig being entered in the UI by the user when the oauth flow is being triggered.

(Note the authConfiguraton could also be retrieved directly from the spec.json from a standardSourceConnectionDefinitionId too, so we wouldn't need to pass it in the API call either)

If the "seeding" is to be done in the UI instead, then I can rename this field to authConfiguration yes
and that'd be extra work to do in the Front-end to handle the input/output from the authConfiguration to merge back into connectionConfiguration
see the thread https://docs.google.com/document/d/1hjyu7hDqXPT1vUtofT7BzkZxDkD5ScpOI3xNAFVlcTs/edit?disco=AAAAQTBC0OQ

[ChristopheDuong]

The second option where the "seeding" is done by the UI would be from this other alternative PR: #7798 (then we can close and not merge this one)