Speed up attachment replication by using a document property to check if there was a change.
The attachment content is NEVER checked, as this configuration expect the document to be modified when an attachment is created, modified or deleted.
In case of conflict, follow the document conflict resolution result.

allAttachments was supposed to return no result in some tests.

ReplicateStorage: fix some attachment replication issues

If the document was deleted, user does not want probably to see it reappear identical.

Drop bulk prototype.
ReplicateStorage: add signature_sub_storage and signature_hash_key parameters.

Speed up document replication by using a document property to check if there was a change.
As allDocs can return this property directly, it reduces the required calculation.

https://developer.mozilla.org/en-US/docs/Web/API/Event/currentTarget
https://developer.mozilla.org/en-US/docs/Web/API/Event/target

event.target is a reference to the object that dispatched the event.
It is different from event.currentTarget when the event handler is called during the bubbling or capturing phase of the event.

Simplify the code, to allow more changes later.

Bulk was implemented to see if it improves ERP5 replication.
Using parallel replication functionality is much more efficient from server and client point of view.

It does not generate huge transaction on server side.
Client does not wait for all documents before writing them locally.

/reviewed-on nexedi/jio!58

/reviewed-on nexedi/jio!57

/reviewed-on nexedi/jio!51

/reviewed-on nexedi/jio!50

/reviewed-on nexedi/jio!48

Fix JIO crash when running inside Safari because of non-existing DOMError object

/reviewed-on !47

Attachments are synchronized only of explicitely activated from the jIO configuration.
Replication deletes a document only if it doesn't contain any attachment.

Thanks to Cedric Leninivin for his work on this topic.

/reviewed-on nexedi/jio!42

It allow to check recursively if a storage support bulk.