* identity: Ensure state is changed on activation
This PR introduces some changes to the way activation flags are
processed in Vault.
Rather than reaching into subsystems and modifying
state from the activationflags package, each plugin can now register its
own ActivationFunc. Updates to activation flags now trigger the the
feature's ActivationFunc, which can encapsulate the associated
subsystem state.
We include a few bugfixes and minor cosmetic changes, like updates to
log lines and godocs.
* Check for nil system backend
* Move deduplication activation to common file
* Add identity dedup activation log lines
* Make interface methods clearer
* Clean up some comments
* More cleanups
* fixup! More cleanups
* fixup! More cleanups
This PR introduces a new type of conflict resolution for duplicate
Entities and Groups. Renaming provides a way of preventing Vault from
entering case-sensitive mode, which is the current behavior for any kind
of duplicate.
Renames append the conflicting identity artifact's UUID to its name and
updates a metadata field to indicate the pre-existing artifact's UUID.
The feature is gated by the force-identity-deduplication activation flag.
In order to maintain consistent behavior between the reporting resolver
and the rename operation, we need to adjust the behavior of generated
reports. Previously, they intentionally preserved existing Group merge
determinism, wherein the last MemDB update would win and all others
would be renamed. This approach is more complicated for the rename
resolver, since we would need to update any duplicated entity in the
cache while inserting the new duplicate (resulting in two MemDB
operations). Though we can ensure atomic updates of the two identity
artifacts with transactions (which we could get for groups with a minor
adjustment, and we will get along with batching of Entity upserts on
load), it's far simpler to just rename all but the first insert as proposed
in the current PR.
Since the feature is gated by an activation flag with appropriate
warnings of potential changes via the reporting resolver, we opt
for simplicity over maintaining pre-existing behavior. We can revisit
this assumption later if we think alignment with existing behavior
outweighs any potential complexity in the rename operation.
Entity alias resolution is left alone as a destructive merge operation
to prevent a potentially high-impact change in existing behavior.
