Use the hardcoded https://validator.erp5.net service
This service is installed with: https://lab.nexedi.com/nexedi/slapos/tree/master/software/htmlvalidatorserver

Add "Post Modules", a serie of modules whose purpose is to track exchanges in/out of ERP5.

Currently, users write Mail Messages (usually as a HTML content), and then send the Mail Message. The RFC5322 version of the email (what is given to MailHost and sent over the network) is generated on the fly and never stored anywhere. About Letter, no output is generated. It means that exchanges are not tracked, and if an Event is sent 2 times, we don't know their exact content on both times.

Posts have the purpose to fix this issue, by creating objects storing the content of the sent Events **exactly as they are transmitted out of ERP5**. In exemple, sent Mail Messages will be converted to a  multi-part message, stored as a Internet Message Post, which content will be transmitted as such to MailHost. For Letters, their content can be processed (by erp5_corporate_identity for exemple), then converted to PDF, and stored as Letter Post. We can then imagine actions/alarms to gather all exportable Letters Posts and mail them to a printer.

Posts follow their own workflow, shared in between all post types, which allow to track which posts are in the sending queue, which have been sent and which have been received. It must be easy to know when an event has been sent several time, and retrieve the content of each of these sendings. Design of the post modules/workflow should also allow an easy customization (for exemple, we may want to send all emails by bulk, instead of  1 by 1, in order to set up mass-emailing policies).

/reviewed-on !532

This mixin contains all the methods returning values based on the mail message
itself contained in the data property of the EmailDocument.

erp5_crm: display standard preview on Mail Message only if internet_message_post_module isn't installed

The attachment field now uses the property aggregate_document_title of Event.

It will be used to differenciate attachments from Mime Post.

This should address two issues:
 1. Allow using a custom python interpreter where all eggs dependencies would already be installed.
 2. The test names did not have stable name, because they were the full path of the folder, which varies from one test node to another. This depends on changes in the profile done in nexedi/slapos!309 .

This changes the internals of `EggTestSuite` so other tests reusing it ( I think we only have [`deploy-test`](https://lab.nexedi.com/nexedi/slapos/blob/41191a29cd16af13b2667d1979f35628c6065fde/software/erp5testnode/testsuite/deploy-test/runTestSuite.py#L151-154) ) will have to be updated once a new `erp5.util` is released. @luke I guess this won't be a problem and this would allow to fix that second issue for deploy test as well, so I did not consider being backward compatible here.

/cc @rafael @alain.takoudjou 


/reviewed-on nexedi/erp5!619

Move Base_checkCloneDocumentPermission beside Base_createCloneDocument

As blobs aren't serializable

Drop usage of cellpadding, cellspacing, border.

2nd try

Calling these can break catalog by not caring about concurrent indexation
activities. Even non-restricted code should not call these, but:
- they cannot be reliably renamed, as there exist activity dependencies
  looking for these exact names (which is a bad practice on its own)
- there is no simple access control mechanism for non-restricted code
So rely on developer discipline instead.

These methods must not be called synchronously:
- they can break catalog by not being careful enough about other
  reindexations which may happen in parallel. See the serialization_tag
  mechanism for more.
- indexation gets executed in the security context of the user causing the
  call, which may lead to an indexation result different from what happens
  when indexation happens with an all-accesses user.

Also, simplify a few scripts while doing so.

The rationale behind this change is to cover the case of sub-documents
modified as part of acquired setters (ex: subordination on Person which
actually sets it on a Career subdocument, or address on Person, etc).
As these value can be passed to newContent (and passed on to
constructInstance) along with immediate reindexation request, caller may
expect these to be also indexed.

"immediate", in this context, means "during the same transaction".
Normally, indexation always happens in a transaction different from the
one which did the indexation-inducing action (modifying a property,
creating a document, explicitely requesting indexation). This is because
SQL and object databases do not have the same approach to conflict
resolution: in SQL, the last one wins, and ordering happens based on locks.
In ZODB, conflict resolution is stricter in that to modify an object
a transaction must have started with the same revision of that object as
the one which is current at the time it is trying to commit. As both
databases must be kept consistent, one interpretation must be enforced
onto the other: the ZODB interpretation. So delayed indexation, plus
careful activity sequencing (serialization_tag) is required.

But in very specific cases, it is actually safe to index a document
immediately: when creating that document. This is because the only
conflict which may then happen is if two transaction produce the same
path, and ZODB will prevent the transaction from committing altogether,
preventing any conflict resolution from happening. Pasting a document
falls into this category as well, for the same reason.

In turn, this feature removes the need to call "immediate" reindexation
methods, allowing to restrict their availability later and preventing
API misuse and catalog consistency compromission.

Two variants of "immediate" indexation are available:
- internal to the method which creates considered document
- delayed to a caller-controller, but mandatory, point later in current
  transaction, by using a context (in python sense) manager object.

Consistently with other methods which may trigger reindexations.