Improve: allow PreSaveEvent listeners to skip default object persistence

[ellenico77]

Summary

This PR introduces a small improvement to the Data Importer flow:
listeners of PreSaveEvent can now programmatically decide whether the current imported object should be persisted or not.

Motivation

In some import scenarios, a listener may fully handle a row (e.g. custom processing, aggregation, side effects) and therefore the default save operation should be skipped.
Before this change, PreSaveEvent listeners could mutate data but could not explicitly prevent persistence.

What changed

• Added a boolean flag to PreSaveEvent to mark save as skippable.
• Added accessor methods on the event (proposed naming: shouldSkipSave() / setSkipSave(bool $skipSave)).
• Updated import processing flow to check the flag after dispatching PreSaveEvent and return early when save should be skipped.

Result

This enables extension points where listeners can:

• process specific rows with custom logic;
• avoid default persistence when needed;
• keep backward compatibility for existing listeners (default behavior remains unchanged).

Backward compatibility

• Default value is false, so existing imports continue to save as before.
• No behavior change unless a listener explicitly sets the skip flag.

Branch compatibility

This improvement proposal is also applicable to the 2.4 branch.

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 New Critical Issues (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[ellenico77]

Hi @fashxp, could you give me your opinion on the event extension proposal? It would be very helpful to me.

If you think it's a good idea, I can reduce the cognitive complexity flagged by Sonar by moving the "if" and the two lines of code above into a new method. However, I think it’s outside of my responsibility, don’t I?