Bugfix gh41477 editbuffer passthrough

[elpaso]

This started as a fix for #41477 but ended up with quite a refactoring.

The basic idea is to make the pass through buffer that we use in transactions to behave like the standard buffer from an API point of view.

I wrote a new test that covers all the cases and expects the same results for transactional and standard buffers:

• add/remove features
• add/remove fields
• change geometry
• change attribute

The test also checks the return values of QgsVectorLayerEditBuffer:

• changedAttributeValues
• deletedAttributeIds
• addedAttributes
• changedGeometries
• deletedFeatureIds
• addedFeatures

[nyalldawson]

Shall we defer to post 3.18.0?

[elpaso]

Shall we defer to post 3.18.0?

Definitely. Some of the changes are rather risky.

[elpaso]

@nyalldawson I don't think this qualifies as a feature, it is a bugfix. I agree it is safer to wait a cycle but IMO it should eventually land in 3.18.

[nyalldawson]

I don't think this qualifies as a feature, it is a bugfix.

Agreed. The "3.20 (feature)" milestone just means the feature freeze date for 3.20. maybe I should rename this as "3.20 (feature freeze)" to clarify?

[m-kuhn]

Should we merge this and delay 3.18 backport by one cycle to 3.18.2? Or is this safe enough to ship with 3.18.1 already?

[elpaso]

Should we merge this and delay 3.18 backport by one cycle to 3.18.2? Or is this safe enough to ship with 3.18.1 already?

I'm not really sure: the test coverage is decent but there are some changes in the transactions code that make me scary. I suspect that the underlying issues never surfaced because the client code in app wraps all commands into macros and does not perform atomic redo/undo.

I think it's safer if we proceed as you suggest.