Add "before" and "after" states + data to EventBus

[dlhck]

Migrated from #3053

Is your feature request related to a problem? Please describe.
Sometimes you need to run a process only if certain condition is filled.

When listening to Entity-updates, the specific data that the process depends on might not have changed and this would cause an unnecessary execution each time the update happens.

Describe the solution you'd like
There should be a "before"-object which contains the Entity-data before the update happened and an "after"-object which would then contain the data after the update.

This way you could filter out the unnecessary code executions by checking if the specific data-field is the same as before.

Describe alternatives you've considered
Include a map of fields that had changes with the before/after-values.

Additional context
N / A

[Ryrahul]

This would be really useful. I've run into this exact problem I have event subscribers that trigger external syncs (e.g., pushing product data to a third-party PIM or order reltaed state changes ) and right now they fire on every update even when the fields I care about haven't changed.
Admin UI sends all fields on every save, not just the ones the user actually edited. So even checking event.input to see if a field was "touched" doesn't help it's always there.

Approach 1: Before-state snapshot Capture a plain data snapshot of the entity before mutation (with any loaded relations collapsed to IDs). Consumer compares whatever fields they care about:

if (event.beforeValues.enabled !== event.entity.enabled) {
    // enabled actually changed
}

Approach 2: Diff map of changed fields — Compute { field: { before, after } } only for fields that actually differ:

if (event.changes.enabled) {
    // enabled changed, event.changes.enabled.before / .after available
}

I'd lean toward Approach 1. Since the Admin UI always sends all fields, a diff map would need to compare every field anyway to build itself so there's no saving in work, it just moves the comparison from consumer-side to service siide. The snapshot is simpler to implement (capture values before patchEntity() runs, no comparison logic in the service layer) and lets the consumer decide what to compare.

the current event system already mostly only gives you scalar columns on event.entity. Most events go through repository.save() which reloads the entity from DB, stripping all non-eager relations. For example, ProductEvent only has scalars + translations, OrderEvent has zero relations, and CustomerEvent only has user. So a beforeValues capturing scalars is consistent with what events already provide consumers already have to re-query for full relational data anyway.

some services (Facet, FacetValue) don't currently load the entity before updating they go straight into translatableSaver.update(). Those would need an extra DB query to capture the before-state.

Would love to see this land. Happy to help test if a PR goes up.