Fix incorrect default on readonly property in our API

[potiuk]

The new version of openapi-spec-validator (0.6.0) started to detect a bug in our API specification - readonly values cannot have defaults (by definition).

This PR fixes the problem and also bumps the openapi-spec-validator to >= 0.6.0 to make sure it is used everywhere.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[uranusjr]

I don’t know what the issue this finds, but if the validator says so, so it is.

[potiuk]

I don’t know what the issue this finds, but if the validator says so, so it is.

It makes no sense to have default on readOnly property.

[potiuk]

default -> what value should be set automatically when we call an API when we miss to set it. This property is only returned by the API, so it should always be present and needs to be set (so there will never be case that we will have to assume some defaults).

[potiuk]

https://swagger.io/docs/specification/data-models/data-types/#readonly-writeonly

TIL:

You can use the readOnly and writeOnly keywords to mark specific properties as read-only or write-only. 
This is useful, for example, when GET returns more properties than used in POST – you can use the same
schema in both GET and POST and mark the extra properties as readOnly. 
readOnly properties are included in responses but not in requests,
and writeOnly properties may be sent in requests but not in responses.

[potiuk]

Static checks passed, API tests passed. merging.