There exists a race in vlib_node_add_next_with_slot.

This is tripping an assert in next frame ownership change by way of the
ip4-arp node. The assert verifies that the node's next array length is
equal to the runtime next node count. The race was lost and the
node next array data was updated in the main thread while the arp code was still
executing in a worker.

This is being hit when many arp requests are being sent from both ends
of a tunnel during which the add next node function is called, which
often has led to an assert b/c the next node array was out of sync with the
runtime next node count.

This is not limited to this situation though as the race is general.