Don't override businessInformation

[ckuijjer]

Summary

This PR fixes/implements the following bugs/features

• Contact information from OpenAPI document takes precedence over user provided businessInformation, see wso2api: businessInformation is taken from OpenAPI document, and can't be overridden #72

Certain fields in the wso2ApiDefinition get defaults taken the OpenAPI document, which can be overridden by the user providing them in wso2ApiDefinition, for example the description, version, and tags.

The fields in businessInformation fields, businessOwner, businessOwnerEmail, technicalOwner, and technicalOwnerEmail however were always taken from the OpenAPI document whenever the OpenAPI document contains a info.contact.email, and were not overridable.

This PR takes defaults these fields from the OpenAPI document only when the user doesn't provide a businessInformation field.

Closing issues

Fixes #72

[ckuijjer]

Note I also added a .prettierrc configuring, as far as I can see, the current way all code is formatted

[flaviostutz]

Looks good! I let a few comments :)

[flaviostutz]

Even if businessInformation is set, we should use the info from info.contact.email/name, don't we?

Maybe we could change the logic to always try to set the info based on "info.contact" if it exists.

What do you think?

[ckuijjer]

That's indeed the general design question we need to find a good answer to! I think there's three options.

Let's take the version field as an example and say the OpenAPI document contains a version with value v1, and the user passes a version with value v2, e.g. new Wso2Api(..., ..., { apiDefinition: { version: 'v2' }, openapiDocument })

1. The values from the OpenAPI document are only used to set defaults in apiDefinition. The user can override this by setting the value in apiDefinition. For the example above, the API gets created as version v2.
2. The values from OpenAPI document take precedence over values provided by the user. For the example above, the API gets created as version v1.
3. A mix of 1 and 2, depending on the field. This is the current behavior on main where description, version, and tags use the OpenAPI as a default, and where the four businessInformation fields always come from the OpenAPI document.

I think option 1 is the best as it gives clear defaults, and allows for the user to override these fields where needed.

Let's take a user that wants to learn about publishing to WSO2 and who takes the Petstore OpenAPI document as an example OpenAPI document. Do we want them to make changes to the OpenAPI document and set its contact information correctly, or do we want them to simply pass the correct contact information when writing the new Wso2API code?

[flaviostutz]

Great summary on this matter! I vote for option 2. As if we go for option 1, then we should change the name of the property to "default info xxx" to make it more clear and we don't want a breaking change now :)

The idea of this property was to be a "sugar" attribute to set these info correctly in OpenAI doc, but I see the mixed behavior causes confusion. So let's go to option 1.

What do you think?