Airspeed Selector: do not run it within the first 2s after system boot

[sfuhrer]

This is to prevent a wrong (false positive) failure detection of the airspeed
shortly after system boot due to delays in driver and/or estimator startup (seen in SITL).

#14807

Describe problem solved by this pull request
In SITL, the airspeed selector has a false positive at startup (probably because there is no airspeed data yet), causing it to first switch to airspeed index -1 (airspeed invalid), and then to 1 (airspeed valid) a bit later once data is there.

Describe your solution
Do not run the airspeed selector as long as hrt_absolute_time() is below 2s.

Describe possible alternatives
Fix it on the SITL airspeed driver side (or if it's not that then find root cause). I think though that waiting 2s after boot until you have an airspeed reading isn't that bad either.

Test data / coverage
SITL tested.

Additional context
#14254 would extend the current preflight checks to prevent arming if the airspeed selector is not up yet or not yet publishing an airspeed (which in this case would be within the 2s after boot).

@dagar is using hrt_absolute_time the proper time measure for this or would there be something more appropriate? When exactly does it actually start counting (when is hrt_absolute_time =0)?

[dagar]

This could be fine as a quick fix for NuttX, although I was wondering if we can do a cleaner job initializing in the first place.

@dagar is using hrt_absolute_time the proper time measure for this or would there be something more appropriate? When exactly does it actually start counting (when is hrt_absolute_time =0)?

Fairly early in system init right before rcS is executed. Note it doesn't start at 0 on Linux.