Enable generated etapi client

[mm21]

This enables etapi clients to be generated using openapi-generator. I've generated the python-nextgen client and verified all CRUD operations for notes, attributes, and branches.

The most sensitive change is adding attributeId/branchId path parameters to postAttribute/postBranch. I realize this may unfortunately break existing clients, but this is a requirement for OpenAPI - all methods need to take the same path parameters. See https://swagger.io/docs/specification/describing-parameters/#path-parameters:

Also remember to add required: true, because path parameters are always required.

The etapi.openapi.yaml changes are to fix validation errors:

• Required fields of Attribute and Branch removed: these schemas are also used for patch wherein those fields can't be updated; generated model then fails validation when it's instantiated
• Pass charset in response content-type: the content-type in Trilium's response is used as a dictionary key, so it needs to match exactly what's provided in the yaml
• Python's built-in regex module doesn't recognize unicode property escapes (\p{L}, \p{N}), so replaced them with [^\s]+ (although this wouldn't be a big deal for me to just change locally)
• Allow underscore in EntityId for branches
• Allow negative timezone offsets
• Add valid note types
• Remove nonexistent required fields from AppInfo

I can work around these issues by modifying etapi.openapi.yaml locally and hacking up the generated code to omit the path parameters in postAttribute/postBranch, so this isn't necessarily urgent, but it would be really useful to be able to generate clients in various languages.

For reference, here's the command I used to generate a Python client:

openapi-generator-cli generate -i etapi.openapi.yaml -g python-nextgen -o ./etapi-client --additional-properties packageName=etapi_client --additional-properties projectName=etapi-client

[zadam]

This change is rather PUT semantics, rather than POST.

Honestly it seems that the ETAPI OpenAPI spec is wrong, because it suggests the POST method requires the ID path param which isn't true. So I think we just need to fix the YAML file to better reflect the existing API.

[mm21]

Agreed, and I tried to do that before by putting "parameters:" under each HTTP method, but it didn't work that way. For some reason I didn't think about moving POST into its own "/attributes" path rather than having it under "/attributes/{attributeId}", same for branches. But that worked like a charm and reduced this PR to only changes in the YAML file which is nice.