isisd: Fast RIB recovery from BFD recognized link failures

isisd: Fast RIB recovery from BFD recognized link failures

Unfortunately as the topotests show a fast recovery after failure
detection due to BFD is currently not possible because of the following
issue:

There are multiple scheduling mechanisms within isisd to prevent
overload situations. Regarding our problem these two are important:

* scheduler for regenerating ISIS Link State PDUs scheduler for managing
* consecutive SPF calculations

In fact both schedulers are coupled, the first one triggers the second
one, which again is triggered by isis_adj_state_change (which again is
triggered by a BFD 'down' message). The re-calculation of SPF paths
finally triggers updates in zebra for the RIB.

Both schedulers work as a throttle, e.g. they allow the regeneration of
Link State PDUs or a re-calculation for SPF paths only once within a
certain time interval which is configurable (and by default different!).

This means that a request can go through the first scheduler but might
still be 'stuck' at the second one for a while. Or a request can be
'stuck' at the first scheduler even though the second one is ready. This
also explains the 'random' behaviour one can observe testing since a
'fast' recovery is only possible if both schedulers are ready to process
this request.

Note that the solution in this commit is 'thread safe' in the sense that
both schedulers use the same thread master such that the introduced
flags are only used exactly one time (and one after another) for a
'fast' execution.

Further there are some irritating comments and logs which I partially
removed. They seems to be not valid anymore due to changes in thread
management (or they were never valid in the first place).

Signed-off-by: GalaxyGorilla <sascha@netdef.org>