As a developer, I want to be able to create a new Wikibase property in its entirety
POST rest.php/wikibase/v0/entities/properties

{
  "property": {
     "data_type": "string" (required)
     "labels": {}, 
     "descriptions": {},
     "aliases": {},
     "statements": {}
  },
  "comment": ... 
  "tags": [ ... ] 
  "bot": false 
}

Acceptance criteria

• 201 response code on success, with JSON representation of the property created (same structure as GET ../property/P123 resource) and location header in the successful creation response
• Ignore HTTP conditional request headers
• Ignore id and type fields, and any unrecognized fields if provided in the request payload
• Error causes to be similar to PATCH properties
• ETag, last-modified and location (URI of the newly created item) as response headers.
• Handle user authentication/authorization like in POST /entities/items/{item_id}
• Client can provide additional edit metadata: mediawiki tags, edit summary text to append to the automated summary, and a bot edit flag, like in POST /entities/items/{item_id}

Error cases to consider

1. 400, value-too-long
2. 400, statement-group-property-id-mismatch
3. 400, referenced-resource-not-found
4. 400, invalid-value (invalid data type should be covered here)
5. 400, missing-field (missing data type should be covered here)
6. 400, invalid-key
7. 400, resource-too-large
8. 403, permission denied (incl. property specific property-create permission)
9. 422, data policy violation (property-label-duplicate and label-description-same-value)
10. 429, request limit reached

Task breakdown

• add to OAS (T377147)
• happy path (T377148)
  • add PropertyCreator interface and implementation
  • include revision ID and last modified date
  • edit summary
• authorization
  • add new method to PermissionChecker::canCreateProperty( User $user ): bool and implement it
• top-level field validation
  • check top level field types
  • check that the data_type field is present
  • consider implementing this as a regular use case validator instead of creating a RequestValidatingDeserializer, because the RequestValidatingDeserializer would only be usable for this one use case
• field validation
• apply middlewares (the usual ones except the one for conditional requests), use UpdateExceptionHandler in the use case, and add the new route to RouteHandlersTest
• spec tests
• mark production ready, update changelog and OpenAPI interface version