Incremental config update limitations

[sukhwinder33445]

Event rule

• Removing an event rule escalation causes the changed_at flag to be updated for all other escalations.
• Adding/removing/updating a recipient causes the escalation and all its recipients to have a new changed_at.

The changed_at column

• It should be added at a central point (Database.php) to avoid future errors.
• It should be precise to milliseconds in order to avoid a data race (daemon side), e.g. if two users update the data at the same time.
• (fixed with Let On_ASSEMBLE_INSERT / ON_ASSEMBLE_UPDATE events handle the changed_at column #227)

[nilmerg]

It should be precise to milliseconds in order to avoid a data race (daemon side), e.g. if two users update the data at the same time.

If two users update the same configuration at the same time, one should get a conflict and need to re-submit. This is no reason to increase precision on the timestamp values.

[nilmerg]

It should be precise to milliseconds in order to avoid a data race (daemon side), e.g. if two users update the data at the same time.

If two users update the same configuration at the same time, one should get a conflict and need to re-submit. This is no reason to increase precision on the timestamp values.

Though, in case it's not possible to differentiate between new and updated entries (which is the case), it is...