Remove use of ChangeSet from RecursivePublishable

[emteknetnz]

RecursivePublishable::publishRecursive() will create a ChangeSet + (child ChangeSetItem indirectly) whenever any object is published. This is at least partially responsible for the large ChangeSet/ChangeSetItem database tables that some websites have.

The ChangeSet functionality is used primarily for silverstripe/campaign-admin. It's believed that the ChangeSet were originally intended to be a more core part of Versioning and facilitate rollbacks, though that's not how rollbacks are implemented right now and it seems very unlikely we'd switch to using ChangeSets

It seems like we should simply remove the creation of a ChangeSet/ChangeSetItem in CMS 6 since the database records created are pretty much pointless

Acceptance criteria

• Stop creating ChangeSet/ChangeSetItem records in RecursivePublishable::publishRecursive()
• ChangeSet_* tables are no longer created by default i.e. delete the ChangeSet_* DataObjects
• Changelog calls out that existing tables will no longer be updated in CMS 6

Kitchen sink CI

• https://github.com/creative-commoners/recipe-kitchen-sink/actions/runs/13298602243

PRs

• ENH Remove use of ChangeSets from RecursivePublishable #490

[mfendeksilverstripe]

Fixes #450

[emteknetnz]

I've had a go at this by essentially just getting the recursively owns objects and calling publishSingle() on them, and then "manually" removing any objects that were in a live only state before calling publishRecursive().

However a handful of unit tests in kitchen sink broke, it seems like there's some difference in how ->Version is "calculated" and thus there's actually big scope to really mess up data integrity here, so I think this approach may be just too risky.

The existing implementation does require the ChangeSet + ChangeSetItem DataObjects to be written to the database. Given this there's no scope to attempt to increase publishing performance by not writing these records, at least not short-term

I might make another PR where we just delete the ChangeSet + ChangeSetItem DataObjects after using them for a recurisive publish, to simply prevent database bloat

Update: OK that doesn't work either VersionedOwnershipTest::testUnversionedPublish() fails. Oh well.

[mfendeksilverstripe]

@emteknetnz Your solution differs from what's I've proposed in #450 . I'll try to put up a PR and see what difference does it make. They key bit here is DBDatetime::withFixedNow which ensures that the versioned records have correct timestamps.

I'll have a another look at this one later.

[GuySartorelli]

Reopening because even if this doesn't get done in time for CMS 6, it's definitely worth looking into for a future major release.

[mfendeksilverstripe]

Encountered the same issue on my test PR: #493

Not sure what the issue is but I'm guessing it may be some undocumented behaviour.I suggest to do a data compare in terms of version records and see what's the difference in terms of raw data. That might help to locate the root cause.