We need to corner possible problems from HELP ticket by detecting stuckness in processing topology changes both at the client and server side.

The main target of such diagnostics is to point to the areas where the processing could be substantially delayed with "in flight" counters - counters that increment on code area entry and decrement (possibly with latency attached) when the control exits the block. This is something that cannot be properly addressed with logging without be unnecessary verbose.

The data that FTDC can display easily is: how many threads are blocked waiting to enter a code section related to RSM (both server and client side) and what is the average latency for the threads that already left that section.