Store and check the CA Certificate Chain to ensure we are talking to the same CA. Save the CA Cert. Chain for future usage.

  and implement other things nicer.

   This allows the administrator set caucase url and invoke bootstrap to set the credentials (user/key to CAU api)

  Ensure it has a new between the 2

   While generate the first certificate include more typical information for the CSR, like city, company, email, state, country.

   Reuse the values from User Certificate to generate the next CSR, in case this API is called by the Certificate Login. This is consistent with the previous legacy API (portal_certificate_authority) that will rely on openssl.cnf defined versions.

   The connector is mostly tests via Person/Certificate Login tests, this tests aims to cover the extra portion.

  Use specific reference reduces the confusion on what default means, since we
  can have multiple connectors for multiple purposes one day.

   Change the property used to clearly identify if this document used caucase or some previous legacy implementation not supported anymore.

   In such case, invalidate the Certificate Login is enough to prevent access.

  This TestCase allows to start a Caucase Server to be
  used on tests. The code is inspired on Kedifa tests.

This is simpler to manage and include extra methods

  This tool will be replaced by caucase implementation and drop
  related code that is not needed anymore

  Rather them use filesystem openssl CA, contact Caucase Service for sign certificates.

  Like it is done for option, remove default from schema after append the value into decription.

This partially reverts 8a336dc5 (erp5_accounting: Allow
Assignor manage Accounting Periods, 2024-09-16) for the restart
transition, it is intentional that only Assignor can restart
an accounting period that have been closed.
The idea was to support a scenario where re-opening a period
that was closed can not be done directly by the Assignee but
needs validation from the assignor.

The check was made on the blob response type, which is set from the
Content-Type header returned by the server, but Safari has a different
interpretation of the charset parameter from the mime type, with a
content type set to application/json;charset=utf-8 like Base_redirect
does today, safari creates a blob with type application/json;charset=utf-8
and this was not detected as redirection and the json returned by
Base_redirect was downloaded. Fix this by checking only the essence
of the type.

This also revealed a potential problem when actually downloading json
files, in that case we also check that we have the X-Location header,
that is supposed to be set by Base_redirect before interpreting the json
and when it's not present we force download.

Follow up of ff624fd2 (ERP5Workflow: newly added permission should be
acquired for all existing states., 2024-11-04) and cbef6282 (ERP5Workflow:
make sure not create duplicate permissions, 2024-11-05)

Fix a problem introduced in ff624fd2 (ERP5Workflow: newly added
permission should be acquired for all existing states., 2024-11-04),
visible in a test failure

before, all permissions became acquired in all states once we update permission list.

See merge request nexedi/erp5!1998