wdog: always ticks++ when wd_start

Now we have CONFIG_USEC_PER_TICK, and for our timer system, all the calculation used 'tick'.
And all the timespec should change to 'tick' before use wd_start(), so USEC2TICK() can NOT be avoided.

Then there must be an 'less then one tick' loss.

One resolution:
ticks++ anyway when wd_start(). But this will caused time expired more a tick.

Another resolution:
Change the testcase, and allow the following logic:

t1 = current_time();
sleep(3);
t2 = current_time();

allow: t2 - t1 >= 3;
(original test must be: t2- t1 > 3)

The original test think the time must be elapse-ing, and the (t2 - t1) must bigger then 3,
but in our system, we use 'tick' as the minimal wdog unit, then there must a precision loss.

Now we choose first resolution.

Signed-off-by: ligd <liguiding1@xiaomi.com>

sched/wdog/wd_start.c

@@ -260,6 +260,23 @@ int wd_start_absolute(FAR struct wdog_s *wdog, clock_t ticks,
       return -EINVAL;
     }
 
+  /* Calculate ticks+1, forcing the delay into a range that we can handle.
+   *
+   * NOTE that one is added to the delay.  This is correct and must not be
+   * changed:  The contract for the use wdog_start is that the wdog will
+   * delay FOR AT LEAST as long as requested, but may delay longer due to
+   * variety of factors.  The wdog logic has no knowledge of the the phase
+   * of the system timer when it is started:  The next timer interrupt may
+   * occur immediately or may be delayed for almost a full cycle. In order
+   * to meet the contract requirement, the requested time is also always
+   * incremented by one so that the delay is always at least as long as
+   * requested.
+   *
+   * There is extensive documentation about this time issue elsewhere.
+   */
+
+  ticks++;
+
   /* NOTE:  There is a race condition here... the caller may receive
    * the watchdog between the time that wd_start_absolute is called and
    * the critical section is established.