Saved object migrations: collect all documents that fail to transform instead of stopping the migration on the first failure

[rudolf]

Similar to v1 migrations, v2 migrations will stop the migration as soon as a document transform throws an exception. v2 migrations should continue trying to transform all documents and collecting any failures. Once all documents were transformed the migration can fail with a complete list of failures allowing users to fix all documents at once.

This was particularly frustrating for v1 migrations, because users would have to manually remove the lock each time a document was fixed, just to bump into the next failing document and having to repeat all the steps again.

v2 migrations improves this slightly, but if there's many failing documents it can still be frustrating to have to restart a migration each time a document was fixed just to find the next problem.

[TinaHeiligers]

Both this issue and #86247 are targeted for the same minor. To avoid too many merge conflicts while working in the same files, this issue should preferably be addressed after #86247 is done.

@rudolf I added a note here.

[TinaHeiligers]

@rudolf I need to connect with you regarding the scope of this work and when we can expect #86247 to be done.

[TinaHeiligers]

@rudolf do you see any issues with the following approach?

At the moment, transformRawDocs uses migrateRawDocs that throws on the first failure. migrateRawDocs is also used in v1 migrations, which we're keeping around for a bit so we'll need a new specific implementation for v2 that doesn't throw.

The new method would return a list of migration docs and a list of failures instead of either returning a list of all docs (success case) or throws (failure case).

We would then need to wait until we've looped through all the documents and no longer need to call OUTDATED_DOCUMENTS_TRANSFORM to fail with the errors collected.

[rudolf]

@TinaHeiligers your plan makes a lot of sense. We could consider changing migrateRawDocs to not throw, and then changing v1 migrations slightly to accommodate the new return signature. If v1 migrations encounters a batch that has > 0 failures it will throw like before. This will hopefully reduce the amount of divergence between v1 and v2 migrations. But either approach is fine since we'll be removing v1 migrations fairly soon (7.14)