handle edge cases when driving transport#tick(now) with nanoTime derived values

Transport#tick is driven with time values representing 'now' in milliseconds. This is often done with System.currentTimeMillis(), however that varies with the wall clock so there are advantages to deriving the value from System.nanoTime() which does not. There are some edge cases the existing tick implementation doesn't handle when doing that (such as values wrapping and a possible clash of actual deadline zero with use of zero as a not-initialized/no-idle-timeout indicator) which could lead to incorrect behaviour and needs addressed.