Leverage Face Status Change Notification to quickly identify and reconfigure upon face creation and removal

[italovalcy]

Hi,

NDVR configures the Faces to listen and send notifications at startup time. However, throughout NDVR execution, faces may be created/destroyed, and NDVR is not reconfiguring accordingly. We should leverage Face Status Change Notification to quickly identify and reconfigure NDVR upon face change events (creation/removal).

More information: https://redmine.named-data.net/projects/nfd/wiki/FaceMgmt#Face-Status-Change-Notification

the Face Manager also publishes notifications when Faces are created, destroyed, go up, or go down. This is done using the postNotification function returned after registering a notification stream to the dispatcher with the name faces/events. Two methods, afterFaceAdded and afterFaceRemoved, that take the function postNotification as argument, are connected to the FaceTable’s onAdd and onRemove signals [18]. Whenever these two signals are emitted, the connected methods will be invoked immediately, where the postNotification will be used to publish notifications through the dispatcher.

Source: https://named-data.net/publications/techreports/nfd-developer-guide/

How to reproduce:

• Execute an experiment and bring the physical interface down (e.g., by running into MininNDN and using something like node.cmd("ip link set down %s" % mcn.intfs[intf].name) -- example available here)
• You will notice that NDVR will not recover from this failure just because NFD will remove the old face and create a new one once the corresponding interface goes DOWN/UP. NDVR depends on sending and receiving interests from the faces connected to other routers, and since the face changed, FIB entries will be outdated (no longer sending/receiving notifications from NDVR)

What needs to be done:

1. Add means to listen to Face Status Change Notifications
2. To allow 1, we should probably change the default FW strategy associated with /localhost/nfd/faces/events from best-route to multicast (defaults to best-route, at least on MiniNDN)
3. NDVR adds proper routes for protocol control messages upon detecting new faces created (TODO: how to filter which faces are interesting for us ?)
4. NDVR updates its internal data structure to remove/add/modify faces updated