Hmmm.... ok so the reason the legacy test passed prior to this change is that DirectUpdateHandler2 (and DirectUpdateHandler from what i can tell) don't bother checking for a uniqueKey (or for multiple uniqueKeys) if allowDups="true" (which it is in the line of ConvertedLEgacyTest that's failing).
So the question becomes: Is it a bug that DUH(2) allow docs w/o a uniqueKey field just because allowDups=true?
If it's not a bug, then this entire patch should probably be rolled back – but personally It feels like it really is a bug: if a schema declares a uniqueKey field, then just because a particular add command says allowDups=true doesn't mean that docs w/o an id (or with multiple ids) should be allowed in to the index – those docs will need meaningful ids if/when a later commit does want to override them (consider the case of doing an initial build w/ allowDups=true for speed, and then incremental updates w/ allowDups=false ... the index needs to be internally consistent.
Actually: I'm just going to roll this entire patch back either way – we can improve the error messages generated by DirectUpdateHandler2 and eliminate the redundant uniqueKey check in DocumentBuilder.toDocument. As a separate issue we can consider whether DUH2 is buggy.