(Cosmetic) updates to models

[CasperWA]

This branch was originally created to test #192, however. Unfortunately it does not fix it, however, I found some minor mistakes in the models and have fixed them here:

• Misspelling BaseRelationshipMeta.
• Rename re-purposed Error model from JSON API to OptimadeError.
• Remove redundant attribute errors in ErrorResponse, which is the same as it's parent model class Failure.
• Change all usages of Set to List (this may not be prudent, but fails for ErrorResponse. So it should either be fixed and returned to its status of Set or not).
  Note, this changes the OpenAPI parameter uniqueItems from true to false (or rather, just removes it).
  Due to an error in pydantic, this is necessary (see my comment here), to keep the OpenAPI schemas reflecting it should indeed be unique items in the respective lists, the uniqueItems attribute is added "manually" through pydantic's Field.
• Updated descriptions for response models.
• Removed redundant meta attributes in response models.

New "major" change:

• Renamed toplevel.py in models to responses.py and moved all non-"final"-response models to optimade_json.py.

[ltalirz]

Thanks @CasperWA

Looks fine to me - although I didn't fully get the reasoning behind the set => list change.

One thing to keep in mind is that list introduces an ordering that people may start to rely on, while set has no ordering.
We should just make sure to use what makes most sense here.
If there is a technical issue to make this change that should be reverted later, keep track of this in an issue.

[CasperWA]

Looks fine to me - although I didn't fully get the reasoning behind the set => list change.

It's also not clear.
The change is done in the models/schema in order to avoid an error that I have a hard time debugging.
In the end, I have an idea of the reason, but I can't always seem to fix it, which is annoying.

One thing to keep in mind is that list introduces an ordering that people may start to rely on, while set has no ordering.

True for Python (and other languages). Not true for OpenAPI / JSON. Here only arrays exist. They are always ordered (as far as I understand).
The change in using typing.Set or typing.List for a model attribute only affects whether or not uniqueItems is set to true or false in OpenAPI for an array.

We should just make sure to use what makes most sense here.

I agree. And the Sets make most sense, I think, for e.g., the top-level data values .... So I will try and see if I can get to work - again.

If there is a technical issue to make this change that should be reverted later, keep track of this in an issue.

I think I will try and fix it here.

Will revert change from Set to List

[CasperWA]

Testing this further I have come to the conclusion that pydantic is doing the verification of Set[BaseModel] wrong, i.e., it is expecting an iterator within Set, whereas I would expect this to mean "a set, where each item is of type BaseModel" - just like the case is for List.

The solution can be to do the following: Set[List[BaseModel]], however, this renders the openapi.json quite useless, since it will be an array of arrays.
Instead, the solution/work-around must be to set it all to List and then "manually" add the uniqueItems where needed to the openapi.json. This can be done in "clever" ways using FastAPI.

Another solution would be to try and fix this in pydantic ...

[ml-evs]

Can't see anything wrong with this, thanks @CasperWA!

I think it's worth raising an issue with pydantic for the Set issue, at least for clarification.