Fixed branch control insertion bug

[Hydrocharged]

A user reported that their dolt_branch_control table was in a corrupted state, as they could not delete a row even though running the appropriate DELETE FROM dolt_branch_control would report that 1 row was affected. Running SELECT showed that it was still there.

I was able to replicate a way of getting the table into that state, which is to insert the exact same row as an existing row but with a larger permission set. dolt_branch_control handles primary key conflicts differently than other tables, as we throw a conflict when a subset is inserted. For example, '%' will match all entries that 's%' can match, so 's%' is a subset of '%'. Of course, when taking permissions into account, 's%' may not be a subset if it has a broader permission set than '%', in which case we want to allow the insertion of 's%'.

The failure case was with exact matches. An exact match is still a subset when the permissions are as restrictive or more restrictive than the original, however it's not a subset when the permissions are broader, and this would result in allowing the insertion of the exact match. We convert all expressions into a specialized integer format, and store those integers in a prefix tree. Since the format will be the exact same, we end up overwriting the old entry, which is an implicit deletion without the accompanying bookkeeping in the rest of the data structure. This is what causes the mismatch, and creates the failure state.

To prevent this, we never allow insertion when there's an exact match, so you must use an UPDATE in such cases. This will prevent that failure mode from occurring.

[coffeegoddd]

@Hydrocharged DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
92ebd4b	ok	5937471

version	total_tests
92ebd4b	5937471

correctness_percentage
100.0

[fulghum]

Looks good!