driver: possible data races in `kick` method

kick method is used to unbury several tasks in the tube. After analyzing this method for drivers fifo, fifottl, utube, utubettl, I came to the conclusion, that it still possible to get a data race and incorrect, unexpected result.

https://github.com/tarantool/queue/blob/aa7c092a1f2ac80d3cfc63c75595d10c5a95c908/queue/abstract/driver/fifo.lua#L158-L173

We take a task with minimal task_id and BURIED status. After that we are updating it, commiting. But lua can also yield before WAL write. So this very task could also be taken in a parallel kick call for the second time.

Possible fix: do changes inside a transaction, like in put, take methods. But there is a subtle point here (which is described in a comment below).
https://github.com/tarantool/queue/blob/aa7c092a1f2ac80d3cfc63c75595d10c5a95c908/queue/abstract/driver/fifo.lua#L101-L117

Start with queue/abstract/driver/fifo.lua lines 158-173 and trace how kick selects and updates buried tasks across fifo, fifottl, utube, and utubettl. Compare this with the transaction handling in put and take at lines 101-117, including the noted subtle point. Done means concurrent kick calls cannot select the same task or produce an incorrect result.