Take min/max batch size into account again for seeding

[roji]

Made MigrationsModelDiffer.GetDataOperations pass through our normal batching logic again, by splitting CommandBatchPreparer.BatchCommands to allow the logic to be called without IUpdateEntries.

On a side note, I was surprised to see we actually have seeding-specific logic for bulk insert... Seeding isn't supposed to be high-perf, and we specifically discourage having a large number of rows (e.g. huge context snapshots), which is where bulk inserting makes the most sense... I'd consider removing it altogether, to simplify the code and avoid bugs (like this one).

Fixes #28876

[AndriySvyryd]

Weren't you able to split the batches in MigrationsSqlGenerator.GenerateModificationCommands? We do want the data operations to be in one "batch" in the migration for readability

[roji]

Sorry, didn't have that in mind when implementing - I agree it's better (and doesn't bake the max batch size into the scaffolded migrations).

Though note that we don't "batch" updates/deletes in the migration for readability, though we could pretty easily do the same we're doing there for inserts. Let me know if you want me to do that.

[AndriySvyryd]

Though note that we don't "batch" updates/deletes in the migration for readability, though we could pretty easily do the same we're doing there for inserts. Let me know if you want me to do that.

I'm not sure about updates, since they could be very different in shape, but we should definitely do it for deletes. However, it's better to file an issue to do it later since batch deletion would be a lot less common than batch insert in seeding.

[roji]

However, it's better to file an issue to do it later since batch deletion would be a lot less common than batch insert in seeding.

Not to be a troll, but every batch insert in Up means batch delete in Down

But of course it's true that Up actually gets used a lot more than Down.

#28956