improving performance of concurrent inserts on innodb with randomized primary
One INSERT per transaction, containing 50 rows, with "consecutive" (or "nearby") PRIMARY KEY values will be optimal, regardless of one or many connections.

Using MD5, UUID, etc, is a disaster for huge tables.  When the table is too big to be fully cached in RAM, the inserts become I/O bound.  In contrast, 50 'adjacent' records will cause almost no I/O.

A secondary index that is a MD5 or UUID is just as bad as the PRIMARY KEY being such.  This is because a secondary key is a BTree, just like the PRIMARY KEY (and the data) is a BTree.  (OK, the secondary key is not quite as bad, because it is probably smaller.)

If you have multiple connections doing inserts, plan on having occasional deadlocks.  Deal with them by re-executing the batch INSERT.

As for "gap locks", first let's get the big picture figured out.  That is, deal with the advice I have given you, and provide a SHOW CREATE TABLE.