Add support for ETL scenarios: dump a full ez installation, transform it, reimport it somewhere else

[gggeek]

In short: we could do a full ezp db dump, doing a breadth-first descent and making sure that user accounts are dumped 1st and contents 2nd.

What would be missing is the handling of object relations: since in ezp relations can be circular, the import should allow creating content even with broken object-relations, and do multiple passes to fix those after all contents have been created.

Note: this most likely depends on issues #34 and #46.

[gggeek]

Prerequisite: #55

[gggeek]

Prerequisite: #56

[gggeek]

Prerequisite: #54

[gggeek]

Prerequisite: #34

[gggeek]

More prerequisites:

• [x] a migration loader that scans directories recursively, as 1M files can not be in a single directory
• [x] a 'migrate' command that uses parallel processing to import contents for speed
• [ ] a command that drops the existing migration table, to ease tests / multiple executions (or allows removing migrations based on regexp matching on name or path)
• [ ] a command that drops all contents except the top-level folders and admin+anon users, their 3 sections, anon and admin roles, for cleanup of target db (this could be probably achieved with existing migration steps, but for speed it is probably better to use custom SQL queries...)
• [x] a 'generate' migration which actually saves files to disk, to be used by the high-level 'export' command
• [x] a way to add settings to tune the way migration definitions are created for content export
• [ ] an 'export' command that splits work in parallel threads
• [ ] an 'upsert' migration for the cases where the target installation already has contents (#245)
• [ ] a flexible way of matching contents between source and export databases by id/remote-id mappers

[gggeek]

Prerequisite: #102

[gggeek]

Steps forward in release 4.4

[gggeek]

Steps forward in release 5.4.1 and 5.5

[gggeek]

Steps forward in release 5.6

[gggeek]

Bugfixes in 5.7.3

[gggeek]

Step forward in release 5.13: Upserts are now possible, albeit in an impractical way: create a migration with 3 steps:

1. load target item by identifier, with allow_null_results and set reference to count
2. create item with if condition: reference equals 0
3. update item with if condition: reference equals 0

@blankse I know this is way late, but it probably is a stepping stone for simplified upsert steps