feat(OpenApiType): Warn about non-required nullable properties

[provokateurin]

Closes #177

[nickvergessen]

Warning: Response definitions: TalkChatMentionSuggestion: Property "statusClearAt" is both nullable and not required. Please consider only using one of these at once.
Warning: Response definitions: TalkChatMentionSuggestion: Property "statusIcon" is both nullable and not required. Please consider only using one of these at once.
Warning: Response definitions: TalkChatMentionSuggestion: Property "statusMessage" is both nullable and not required. Please consider only using one of these at once.

🤷 What problem that does not exist are we trying to fix?
A user status consists of status, message, icon, clearAt, … All but the status are nullable.
Feels weird to me that we have to crash the API and in all clients have to check if each attribute of the status is actually available?

Warning: Response definitions: TalkParticipant: Property "phoneNumber" is both nullable and not required. Please consider only using one of these at once.
Warning: Response definitions: TalkParticipant: Property "callId" is both nullable and not required. Please consider only using one of these at once.

Similarly in Talk we use the same ResponseDefinition for normal and moderator users, so everything that only moderators can see is "not required". But they can still be null in those cases

[provokateurin]

What problem that does not exist are we trying to fix?

I consider it bad design, because these are two different concepts to say a value is not present. In Javascript you can see this perfectly, because these fields could have the value null or undefined and you'd have to check against both.

Feels weird to me that we have to crash the API

Crash? This is only a warning you can ignore without consequences.

in all clients have to check if each attribute of the status is actually available?

Depends on how the clients handle the data. Some will handle these cases the exact same way (by using null as the value), some like Javascript are better due to the problem I outlined above.

Similarly in Talk we use the same ResponseDefinition for normal and moderator users, so everything that only moderators can see is "not required". But they can still be null in those cases

No problem with that. You can just keep it that way. I personally would only use null for this case as the differentiation if a user is a moderator or not shouldn't be based on the availability of some properties.