rose: use timer_shutdown_sync() for t0timer teardown

[f6bvp]

rose_t0timer_expiry() re-arms itself via rose_start_t0timer() at its
own tail. rose_neigh_put() and rose_remove_neigh() stop it with
timer_delete_sync() before freeing (or unlinking) the neighbour, but
that only guarantees the callback is not running at the moment the
call returns -- it does nothing to stop the very invocation that was
just waited out from re-arming the timer on its way out. That re-arm
races the kfree() in rose_neigh_put(): the timer can fire again on
freed memory, and rose_t0timer_expiry() -> rose_transmit_restart_request()
-> rose_send_frame() -> ax25_send_frame() dereferences the freed
neigh->digipeat, use-after-free.

This matches a syzbot report (KASAN slab-use-after-free read in
ax25_find_cb()) that stayed open with both cause and fix bisection
failing -- consistent with a hole that timer_delete_sync() alone
cannot close for a self-rearming timer, a case documented in its own
kerneldoc ("there is no way to get this correct with
timer_delete_sync()").

Fix: use timer_shutdown_sync() instead in both call sites. Unlike
timer_delete_sync(), it also marks the timer so that any further
add_timer()/mod_timer() on it is silently ignored, which closes the
window regardless of how the self-rearm and the free are interleaved.
ftimer's handler is a no-op and never re-arms, but it is switched the
same way for consistency: both timers are being torn down for good in
both of these call sites.

Reported-by: syzbot+caa052a0958a9146870d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d

Single commit, applies cleanly to current main.