Introduce soft deleted list option for soft deletable entities

[strailov]

Add soft_deleted_mode query parameter to listing REST endpoints

Summary

Introduces a soft_deleted_mode filter parameter to all soft-deletable entity listing endpoints, allowing API consumers to query soft-deleted entities that were previously hidden from listing results.

Motivation

Soft-deleted entities (Distribution Sets, Software Modules, their Types, and Rollouts) were previously only accessible by direct ID lookup. There was no way to list or search them via the REST API, making it difficult for UI and integrations to display or manage deleted resources.

Changes

New API contract:

• SoftDeletedMode enum (only_soft_deleted, exclude_not_soft_deleted, include_soft_deleted) with safe fromValue() parsing
• SoftDeletableRepositoryManagement interface extending RepositoryManagement with findAll(SoftDeletedMode, Pageable) and findByRsql(String, SoftDeletedMode, Pageable)
• count(SoftDeletedMode) added to RepositoryManagement with fallback for non-soft-deletable entities

Affected REST endpoints:

• GET /rest/v1/distributionsets
• GET /rest/v1/distributionsettypes
• GET /rest/v1/softwaremodules
• GET /rest/v1/softwaremoduletypes
• GET /rest/v1/rollouts (compact mode only; full mode intentionally excluded)

Mutation guards:

• update, lock, unlock, invalidate, assignTag, unassignTag now reject operations on soft-deleted entities with DeletedException

Implementations:

• JpaDistributionSetManagement — refactored findByRsql to support deleted filter while preserving legacy complete field handling
• JpaSoftwareModuleManagement, JpaSoftwareModuleTypeManagement, JpaDistributionSetTypeManagement — added findAll/findByRsql with soft-delete filtering and update guards
• JpaRolloutManagement — added findAll/findByRsql with SoftDeletedFilter
• Chosen that approach instead of introducing this logic in AbstractJpaRepositoryManagement due to that some entities are not soft-deletable by definition. So the current approach may have some duplications with findAll or findByRsql implementations but seems with more clear architecture approach and distinguish those entities.
• Soft-delete mutation guards - Soft-deleted entities must reject mutation operations (like Rollout already does). Users can stumble into "Entity exists" errors due to unique key constraint violations on soft-deleted entities they cannot see. Here I rejected the approach with intermediate class due to AbstractJpaRepositoryManagement → AbstractJpaRepositoryWithMetadataManagement - Would need two variants (with/without metadata) or force unrelated coupling. Not worth the complexity. Decided to override the updates for each entity which is easy to review, no risk for other entities and straightforward .
• Reject all for bulk updates - to be still considered ...

[avgustinmm]

If you extract soft deletable interface SoftDeletableRepositoryManagement - this count method shall go there

[avgustinmm]

don't we want here count with soft deleted mode?

[strailov]

I even started to think - why we need count at all ? Previously Slice it was used - that's why count was invoked, but It seems everything is page now - meaning why do we need count at all since we have it into the page ?

[strailov]

This probably would eliminate the need of count(SoftDeletedMode) at all.

[avgustinmm]

currently there is softe deleted support here, see supportSoftDelete0, isNotDeleted0 that automatically resolve if there is soft deleted support or not.
So there are two options:
A) stick to this support, and implement using that mechanism, eventually AbstractJpaSoftDeletableRepostioryManagement (or this class to extend and implement SoftDeletableRepostioryManagement)
B) remove soft deletable mechanism from here and move the support entirely into AbstractJpaSoftDeletableRepostioryManagement
Anyway I think a dedicated abstract class with impl of SoftDeletableRepostioryManagement will help to minimise boilerplate code

[strailov]

It's not that simple I think - DS & SM extend AbstractJpaRepositoryWithMetadataManagement but other entities don't - they lay on AbstractJpaRepositoryManagement . So it again leads to not so clean separation ...
We would have to add also AbstractJpaSoftDeletableRepositoryWithMetadataManagement for DS & SM eventually ?