[dv] The #1ps delay in dut_init means we never start a sequence item on the first clock edge

@rswarbrick is already working on this.

Since Jan 28, 2022.

This seems like a bad idea because "valid is asserted on the first clock" is the sort of situation that could trigger a HW bug.

This delay (in `dv_base_vseq::dut_init`) dates back to an old commit (6d31a7c). I think I managed to trigger the problem that it's trying to work around last night. We've got a task in the TL host driver called `flush_during_reset()`. When we're in reset, this pops and discards any sequence items that come in. Unfortunately, if a sequence item arrives at the same time as we come out of reset, you can end up in a situation where we kill the thread that was popping and discarding the items at the wrong point, leaving things out of whack and getting a UVM error.

Do we actually need to discard TL items that arrive when we're in reset? If not, we could flush the queue as we go into reset (or 1ps after, if we're worried) and not have to worry about this synchronisation at all.

@weicaiyang: I think you've looked at this code last? @sriyerg: Since you might have an opinion about whether this is something we need to worry about.