also str representation of unicode character is different.

See merge request !1768

The way addToDate was working with dates was not good, and creating
confusion when removing 1 month from the last days of a 31-day month, as
the previous day had less days than the current month:

date = DateTime(2023, 5, 31)
print date
print addToDate(date, month=-1)
> 2023/05/31 00:00:00 GMT+2
> 2023/05/01 00:00:00 GMT+2

This was even more confusing in March, with february having only 28
days:

date = DateTime(2023, 3, 31)
print date
print addToDate(date, month=-1)
> 2023/03/31 00:00:00 GMT+2
> 2023/03/03 00:00:00 GMT+2

The new behavior is to, when removing a month, if the new day of the new
month is more than the number of days in month to default to the last
day of the month. For exemple, removing one month from 31/05 becomes
30/04, and from there it will add/remove the days as necessary.

The real issue being that removing a month is ambiguous and can mean
a different thing for different people.

For reference, the reference implementation of timedelta in python
doesn't support adding months:

https://docs.python.org/3/library/datetime.html#datetime.timedelta

I hope my solution will make the more sense in ERP5's context.

For zope, a request to /erp5/person_module/person1 or
/erp5/organisation_module/person_module/person1 can both be resolved
and are (more or less) equivalent. This change brings support for
similar request paths for Open API Connectors.

( until we finalize the complete integration of SlapOS parameter
editor )

We set the module as a source to acquire roles. Also, we need to store request and response in HTTP Exchange.

This merge request is to fix ec4a3f9d

See merge request !1771

We set the module as a source to acquire roles. Also, we need to store request and response in HTTP Exchange.

This is a simple framework to implement services in ERP5 based on an
OpenAPI document.

A new type "Open API Type" (similar to "Base Type") is introduced,
this is responsible for the definition of operations and types.
The Open API document is set as text content of the Open API Type
and can be edited from the Open API Type.

For each service, a new portal type will be created. The portal type
use OpenAPIService as class and this is responsible for serving
requests. The process of serving requests is:
 - find the matching operation from the request method and request
   path
 - extracting request parameters and request body using the parameter
   definitions from the Open API Document
 - validate parameters and request body according to the schema from
   the Open API document
 - finding the method, this is done by using _getTypeBasedMethod with
   the operationId
 - calling the method and formatting the result or handling error.
   The default handling of errors is to reply with rfc7807 json
   responses, but it can be customized by defining an
   `handleException` type based method.

Typically, the services will be created in portal_web_services. From
there, there is also a view using a new SwaggerUI gadget to try out
the API.

What's not supported:
 - OpenAPI document in YAML format is only partially supported and
   have some limitations over JSON:
    - On python2 the order of operations is lost, the lookup of
      operations is not made in the order of the operations from the
      document. Also the operations are not in order in the SwaggerUI
      gadget.
    - The text editor does not provide rich editing of YAML
 - "partial" parameters in path elements ( /users/{user_id} is
   supported, but /documents/report.{format} is not )
 - XML (decoding of request bodies and parsing of responses) is not
   supported.