[GEOS-10561] CatalogImpl.save(StoreInfo) business rule to handle ResourceInfo.namespace

[groldan]

CoverageStoreEditPage and DataStoreEditPage duplicate code for a poor job trying to maintain the consistency between a StoreInfo workspaces and its children ResourceInfo namespace properties.

Going through, and saving all the StoreInfo's resources disregarding whether the store has been assigned a different workspace doesn't only waste resources and slows down the update store operations in both web and rest, but produce as many update events as resources in the store, which are no-ops, but can trigger unnecessary side effects from catalog listeners.

Keeping the resources namespace in sync with their store's workspace is clearly a Catalog business rule instead.

Remove the duplicate eager resource update code from CoverageStore and DataStore edit pages, and implement the consistency enforcement as a Catalog.save(StoreInfo) business rule, avoiding going through the list of child resources if not needed, and ensuring the operation is rolled back with counter-actions if anything fails.

Checklist

• [x] I have read the contribution guidelines.
• [x] I have sent a Contribution Licence Agreement (not required for small changes, e.g., fixing typos in documentation).
• [x] First PR targets the main branch (backports managed later; ignore for branch specific issues).
• [x] All the build checks are green (see automated QA checks).

For core and extension modules:

• [x] New unit tests have been added covering the changes.
• [ ] Documentation has been updated (if change is visible to end users).
• [ ] The REST API docs have been updated (when changing configuration objects or the REST controllers).
• [x] There is an issue in the GeoServer Jira (except for changes that do not affect administrators or end users in any way).
• [x] Commit message(s) must be in the form [GEOS-XYZWV] Title of the Jira ticket.
• [x] Bug fixes and small new features are presented as a single commit.
• [x] Each commit has a single objective (if there are multiple commits, each has a separate JIRA ticket describing its goal).

[jodygarnett]

@groldan with release happening in the coming weeks did you wish to check back on this activity?

[jodygarnett]

I really like this change; is it ready to go? I do not see any further action beyond your unresolved discussion above?

I was hopeful that this fix could help prevent https://osgeo-org.atlassian.net/browse/GEOS-10490

[groldan]

Hi Jody/Andrea. I'll try to update the PR following Andrea's idea of using a listener instead as soon as possible. Doing so may not be as straight forward though, since it'll need to be split into pre and post event listeners, and in the event of a save failure I think a post-save event is not being triggered, so we wouldn't be able to rollback?

This was a contribution from a patch that's already integrated into geoserver cloud, and I found it difficult to find the time to follow through.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. Please re-submit with updates if you want to resume work on this topic. Thank you for your contributions.