Avoid fatal errors when unable to offline a feature geometry or failing to commit changes into the offlined layer

[nirvn]

A client reported a packaging job error when using the optimized packager.

The issue here has to do with how the legacy packager's QgsOfflineEditing class handles a failed layer commitChanges vs the new packager.

With the old packager, a warning was being thrown: https://github.com/qgis/QGIS/blob/master/src/core/qgsofflineediting.cpp#L866-L868

With the new package, we use the QGIS edit utility class (https://github.com/opengisch/libqfieldsync/blob/master/libqfieldsync/offliners.py#L331) which raises a fatal exception if the offlined features can't be commited (https://github.com/qgis/QGIS/blob/master/python/PyQt6/core/additions/edit.py#L38).

This PR aligns the behavior of the new optimized packager to only show a warning instead of derailing the whole packaging job.

In addition, code as been added to insure that the geometry inserted into the offlined geopackage layer is compatible with the data provider. If it is not compatible (the client issue to begin with), we skip individual feature offlining instead of breaking the whole layer.

[suricactus]

I am not sure if this is a fixing or introducing a bug here tbh...

I would presonally prefer to have my package job fail and see that clearly, instead of silently accepting a failing conversion. I have a distant memory that we agreed back then that the minioffliner better fails faster.

If we really want to support the old behaviour, I would suggest we introduce a new packager, minioffliner_compatibility, which handles those shady areas closer to what it used to be in QGIS Offlining.

@m-kuhn opinions?

[nirvn]

@suricactus , -1 on introducing another packager.

The QGIS processing toolbox has the ability to skip invalid geometries, we should too ;) there are warnings thrown into the logs of the packaged job, so it's not silent to administrator.

For the average user, I am not sure a failure is better than a missing feature.

In any case, I'd argue that even if we want to hard fail on an invalid geometry, I'd rather have the error tell me which feature ID let to the failure instead of a generic "145,692 features couldn't be added" :)

[suricactus]

I think what is worth it that we catch the warning and put it more prominent. We already have the framework for this with Project.problems in QFC. Most of the people do not look at the logs of the jobs (no data to prove, a strong feeling dealing with support).