[DISCUSS] Virtual attributes management refactoring

Tracked as SYNCOPE-709.

Current implementation

As reported, virtual attributes are attributes whose ownership is not of Syncope but of one or more external resources; such resources are said to be the linking resources for the given attribute.

A virtual attribute needs to be explicitly assigned, e.g. instantiated from a given virtual schema, to a given user (or group or any object).

Virtual attributes can be part of mapping for one or more resources:

• in propagation -> to set value(s) on the linking resources or other resources
• in synchronization -> to set value(s) on Syncope from linking resources

At operation level:

• values must be fetched when reading users (groups, any objects) via REST - if mapped
• effective read invocation on the underlying connectors is reduced by using cache
• virtual attributes are populated into users (group, any objects) exclusively by VirAttrHandler, only when strictly required
• user (group, any object) update is often problematic: virtual attributes to be removed and updated need explicit management in PropagationManager
• when the same attribute is mapped for different resources (linking or not), a list of values is generated and it is not clear where the ownerships comes from

Refactoring proposal

1. when defining a virtual schema, it is mandatory to define the linking resource(s)
2. virtual attributes are not assigned any more to users (groups, any objects) but, as long as an user (group, any object) is assigned the AnyTypeClass of which the virtual schema is part, it is also assigned the related virtual attribute
3. mapping:
   1. linking resource(s) have, besides traditional mapping items, one or more linking mapping which derives from virtual schema definition (see above)
   2. virtual attributes can only be mapped for propagation to non-linking resources (as, because of linking mapping, are already mapped both in propagation and synchronization to linking resources)
4. Syncope will autonomously decide when to read or to write (as part of propagation) virtual attributes' values from linking resources

The overall virtual attribute management is greatly simplified; as an additional bonus, this proposal does not touch neither REST endpoints nor transfer (TO) or patch objects.