feat(openapi): Add more type/int limitations

[nickvergessen]

• Would something like this be desired @provokateurin
  Is a break like this okay?
• Is it a good/okay idea to ease reusing as a API developer to introduce a subtype for things like CALL_FLAGS or is that confusing?

[provokateurin]

This is a nice improvement, everything should be documented as strictly as possible.
It's not even a breaking change, since the API is the same and only the documentation for it has changed. To the end user this is not a problem, except for the case where they generate code from it, but then they have to deal with it themselves and it doesn't concern these changes.

[provokateurin]

Also adding extra type aliases is helpful, otherwise code generators will need to come up with names and they can be ugly (and ofc then they are re-usable which also helps a lot).

[nickvergessen]

Okay thanks, then I will check if there are more things to adjust and then start fixing false-negative psalm complaints

[provokateurin]

The psalm complaints might be legit though

[nickvergessen]

No, we just don't have get*() declare that they return the consts…
So yeah "legit" by psalm, but not "broken code".

[nickvergessen]

Pushed the current state, but

spreed/lib/Model/BotServer.php

Lines 15 to 18 in 1ccbf67

	* @method void setName(string $name)
	* @method string getName()
	* @method void setUrl(string $url)
	* @method string getUrl()

is a bit annoying. It does not allow to specify non-empty-string and therefore psalm afterwards complains. Similar problem with all int fields

[nickvergessen]

Suggested change

	* recordingConsent: 0|1|2,
	* recordingConsent: 0|1,