OPTIM: stick-table: avoid atomic ops in stktable_requeue_exp() when possible

OPTIM: stick-table: avoid atomic ops in stktable_requeue_exp() when possible

Since the task's time resolution is the millisecond we know there
will not be more than 1000 useful updates per second, so there's no
point in doing a CAS and a task_queue() for each call, better first
check if we're going to change the date. Now we're certain not to
perform such operations more than 1000 times a second for a given
table.

The loop was modified because this improvement will also be used to fix a
bug later.