Classification type uuids can be changed with PUT leading to inconsistent behavior
Description
When invoking PUT /classification-types/{uuid}, if the PUT body contains a different UUID than on the URL and the UUID on the URL already exists, the PUT succeeds.
The database has the new UUID as the jsonb "id" while the DB's "_id" column contains the original UUID.
When accessing this classification type, the "id" in JSON is, as far as I can tell, always replaced with the original ID. However, when searching via the GET /collection-types, if the query uses the original UUID, nothing is returned. If the updated UUID is used, the classification type is returned, but has the original UUID in the JSON.
For example: GET /classification-types?query(id==11111111-1111-1111-1111-111111111111) where in the DB _id=11111111-1111-1111-1111-111111111111, jsonb={"id": "11111111-1111-1111-1111-111111111112", "name": "xyzzy"} returns an empty array, whereas GET /classification-types?query(id==11111111-1111-1111-1111-111111111112) returns an array with: {"id": "11111111-1111-1111-1111-111111111111", "name": "xyzzy"}
PUT should not be able to update the "id" field of an existing entry.
When invoking PUT /classification-types/{uuid}, if the PUT body contains a different UUID than on the URL and the UUID on the URL already exists, the PUT succeeds.
The database has the new UUID as the jsonb "id" while the DB's "_id" column contains the original UUID.
When accessing this classification type, the "id" in JSON is, as far as I can tell, always replaced with the original ID. However, when searching via the GET /collection-types, if the query uses the original UUID, nothing is returned. If the updated UUID is used, the classification type is returned, but has the original UUID in the JSON.
For example: GET /classification-types?query(id==11111111-1111-1111-1111-111111111111)
where in the DB _id=11111111-1111-1111-1111-111111111111, jsonb={"id": "11111111-1111-1111-1111-111111111112", "name": "xyzzy"}
returns an empty array, whereas GET /classification-types?query(id==11111111-1111-1111-1111-111111111112)
returns an array with: {"id": "11111111-1111-1111-1111-111111111111", "name": "xyzzy"}
PUT should not be able to update the "id" field of an existing entry.