Distribution Set implicit lock: Support testing mode

[avgustinmm]

With implicit lock (locking DS on auto/manual assignment and rollout) the DS became immutable in an assignment. This leads to a problem with the use case of testing a DS. Though one could always create 1.0.RC1 -> test -> 1.0.RC2 -> test -> 1.0, it could be a little bit unpleasant for the user. So, it makes sense to add support for testing mode. Current approaches that have been considered (in the scope of Software Module & Distribution Set lock / immutable discussion:

1. Based on a tag of Distribution Set the implicit locking could be skipped. We could define a tag, e.g. "test", and if a DS is tagged with it - it won't be implicitly locked. We could even go further - we could leave the user an option to define names or names of tags that will be interpreted as "test" DS.

   • advantages:
     • no additional flags in the database or the API will be needed.
     • you could define different modes in which you want to bypass implicit lock - e.g. "test" & "demo"
     • once starting with the pattern of assigning a 'functional behavior' to the tag semantics leaves open the door for the application of such an approach in other places instead of the cumbersome polluting of db and APIs with flags for every insignificant feature as, for instance, 'required migration step'
     • having implemented test mode as tags allows easy integration of searches - you could just search by tags in order to find out what are your test DS (for instance to delete them when not needed)
     • easy to implement
   • disadvantages: this implementation is more 'declarative' so it shall be better documented and will need more 'user awareness'. This however could be easily hidden by the UIs.

2. Allow an unlock in order to modify, at the user's responsibility.

   • advantages:
     • relatively easy for the user to find out how to modify DS
     • easy do implement
   • disadvantage: leaves the user with an easy option to overcome, hence abuse, with that option.

3. Add "do not lock" option for all manual / auto assignments and rollouts (assumption is - lock by default - in order to keep system safe by default)

   • advantages:
     • easy to use
     • relatively, easy to implement
   • disadvantages:
     • affects multiple APIs.

[avgustinmm]

Implemented as follows (multiple options are available to support testing mode)

1. add unlock() method of the REST API - so, for a distribution set for testing purposes could be unlocked explicitly - don't use it otherwise
2. add tenant level configuration property - implicit.lock.enabled, true by default which could disable implicit lock per tenant
3. add support for a configurable set of tags (RepositoryProperties.skipImplicitLockForTags, by default skip-implicit-lock, _skip_implicitlock, _SKIP_IMPLICITLOCK, SKIP-IMPLICIT-LOCK) which disable implicit lock for distribution sets tagged with them