Dupe improve custom data handling
The current custom data handling code does the following
1) For normal single rows it first inserts a row. This has the impact of rendering the
update that follows meaningless (this was an intentional change). It then deletes the row.
Hence the upshot is simply that it deletes the row. A separate process transfers the custom
data for the row. In other words we are engaging in 3 queries with a fairly high chance of
causing deadlocks in order to just delete the row.
2) For single rows where the entity reference refers to the merged contact the row is
updated to refer to the merged contact (without the insert this works) and a further unnecessary delete follows
3) For custom groups supporting multiple rows the rows are updated to have the new entity id. An unnecessary delete follows.
This change only affects the first of these. I would like to, in a future PR, change UPDATE IGNORE to just UPDATE &
remove the unnecessary delete - with more testing.
Note that this does include a slight change of behaviour. Currently if ANY fields in a custom group
are transferred from one contact to another during merge the row is deleted (with all the custom fields in it).
However, if no fields in a set are deleted then the row is not deleted.
This felt like it was a bit short on consistency. If has a potential advantage from a DB size point of view (any
deleting is better than none) but it also increases the number of locking queries in a process that is fairly
prone to cause DB locks. Based on these considerations I didn't think it worth re-adding code complexity to
retain inconsistent deletion.
A note on tests - I pre-added a bunch of tests into _api3_ContactTest to cover the 3 scenarios above.