Handle schema merge for column and FK drop automatically

[fulghum]

A customer hit a schema merge conflict because their table had dropped a column, an index, and a foreign key. This is a case that Dolt should be able to merge automatically, but for some reason, the merge reported it as a schema conflict and did not allow the user to use the new automatic schema resolution tooling.

Part of the problem here is that we hit the old schema merge guard we had in place before we added support for automatic schema merging. PR #6349 removes that guard, but needs a little more testing to make sure all the cases there are covered by the schema conflict resolution code. Once this is removed, the schema merge code may be able to automatically handle this merge without requiring user intervention.

Next steps:

• complete the work in Removing old schema merge guard  #6349 to remove the old schema merge guard
• add a new test for a merge where a column, an index on the column, and an FK for the column are dropped on one side of the merge
• get the test case above to merge automatically without requiring manual schema altering

[fulghum]

I tried to repro this today, but wasn't able to yet. The diff we saw earlier, from the customer, showed a table where a column used in an index and in a FK reference was dropped, but that doesn't seem to be enough to repro the same error message the customer was seeing – in all my attempts, that schema change merged smoothly and automatically.

Next step is seeing if we can get a clone of the database from the customer, then re-running the same merge and catching the problem in the debugger.

[fulghum]

I was able to repro this with the customer's database this morning and, as expected, the old schema-merge-guard code was getting in the way. It had a mapping of the columns from the old schema to the new/target schema and made an incorrect assumption that because there was a gap in the mapping (from a column being removed) that the remaining columns were newly added columns and when that column wasn't nullable and didn't have a default, the code got confused and errored out the merge. The assumption that code made was probably true before we added support for schema merge, but it's definitely not true anymore.

Once I removed the schema-merge guard code, this merge passed cleanly as expected.

I'm going to dig into that old schema-merge guard code today, make sure we have all the cases it hit covered with tests and then get it removed asap.

[fulghum]

The last step of this work was to remove the schema merge guard code, which was finished last month.