Policing method to deal with Thread networks where leader is holding on to stale service entries (e.g. srp)

[ndyck14]

This relates to issue #9415. For a network in this state, Leader must be updated to new code from #9415 which may be insufficient to address the serverity of the issue for the rest of the mesh.

We need a way for updated nodes to police affected leaders. One option could be leader takeover. @abtink described other possibilities, which I do not understand yet.

cc @jwhui @BL451

[abtink]

@ndyck14 the policing mechanism I have in mind is not a small/simple change and may require new text in spec and/or feature design.

The core of the idea is to try to use existing kUriServerData TMF message mechasnim where a device can send a request to leader to remove all netdata for a given RLOC16. This is used today by a parent node when one of its children is removed to request any netdata entry previously added its child to be removed. I beleice the same message/mechansim can be used to have a BR request entries added by another BR to be removed.

[ndyck14]

in concept, it seems straight forward: a node with updated code can observe netdata and compare it against router table. for any discrepancies, it can set some reasonable timer + jitter after which it checks again, and if the state remains, issues a command to zero the netdata for that RLOC. For now, it does not appear spec expressly prohibits this (although it does seem a slipperly slope). How long might netdata come before an updated router table (the valid case that needs to be distinguished from the otherwise invalid precipitator in #9415)?