My change to the "listIndexes" IDL (SERVER-52545) has caused an intermittent failure in jstestfuzz_replication_initsync, I think this is the sequence:

• the fuzzer generates a createIndexes command like {createIndexes: [ {key: "foo", dropDups: "some string"}]}
• that's wrong because "dropDups" is supposed to be a bool, but createIndexes succeeds anyway (its parameter validation is spotty, awaiting SERVER-52539) and creates a corrupt catalog entry
• subsequent "listIndexes" commands fail with a uassert, because they now strictly parse the catalog entries. The message is like: "Could not parse catalog entry while replying to listIndexes"
• initial sync is now impossible because the sync source can't answer "listIndexes". The initial-sync node crashes, logging:

  > "Fatal assertion","attr":{"msgid":40088,"error":"InitialSyncFailure: error cloning databases :: caused by :: Location5254501: Error cloning collection 'qa450.existingname' :: caused by :: listIndexes failed: { ok: 0.0, errmsg: \"Could not parse catalog entry while replying to listIndexes\", code: 5254501, codeName: \"Location5254501\",
  

  This may be fixed by SERVER-52539 "Specify input/output to createIndexes command in IDL", which will make createIndexes as strict as listIndexes. But I want to fix the BF sooner than that, so this ticket is a bandaid. Besides, there may be value to validating index options at several levels, that'll be more clear once SERVER-52539 is done.

(In retrospect, we should've converted createIndexes before listIndexes, but I didn't anticipate this issue.)

I made createIndexes validate the "background" option in this commit, now I'll validate the rest of the options.