TASK: Remove references to CommandResult in return types

[mhsdesign]

Followup to #5059

Extracted from #4988

We will remove the result object for now since we removed the ->block() earlier and currently have no information we need to pass to the user after calling $cr->handle(). In the future we can still add an object if deemed necessary as its non breaking.

Upgrade instructions

Review instructions

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[bwaidelich]

I'm not 100% sure whether it might be useful to have some return type that tells something about the published events (e.g. last sequence number) and maybe even about the updated/skipped projections

[mhsdesign]

yes but id rather discuss this in #4988 or an issue?
This was just meant so these files dont have to be adjusted with your pr. I checked out these files and voila ^^
For more transparency i would actually prefer at first to set some correlation metata in the events itself for node migration and then we can improve cli output.
Your pr can very well introduce some Result object, but that doesnt have to be used yet here.

[kitsunet]

I am fine either way, CommandResult sounds right, we might just replace the inner workings and keep it around?

[bwaidelich]

I am fine either way, CommandResult sounds right

yes, my thinking. Does it make sense to remove the class if we re-add it a couple of PRs later?

[mhsdesign]

Okay so then lets not remove it via your pr #4988:
and we can close this for now and reopen for the case we want to get rid of it.

[mhsdesign]

As discussed with @bwaidelich we will remove the result object for now as the skipping of projections will be superseded soonish and we dont have a reason for a result. In the future we can still add an object if deemed necessary as its non breaking.

[kitsunet]

I am really unclear what changed about the reasoning to maybe keeping it around for the future, but 🤷

[mhsdesign]

Bastian and me discussed it in detail that neither the highestCommittedVersion or highestCommittedSequenceNumber from the CommitResult of $eventStore::commit() are relevant to be returned from the content repository, nor the - currently still - skipped projections. Also if we have a clear usecase we can reintroduce it. On the road to creating a release candidate we should remove the code that we were not sure we would like to keep as releasing this unfinished is meh^^