ospf6d: reset areas and redistribution at router-id modification

ospf6d: reset areas and redistribution at router-id modification

The ospf6 router-id is provided by order of preference by:

 ospf6d itself if the "ospf6 router-id X.X.X.X" command is set.
- zebra. If the "ip router-id X.X.X.X" zebra command is set, the
  configured IP is provided as the ID or alternatively the highest
  loopback IPv4 address or else the highest interface IPv4 address.

The running ospf6 router-id is stored in ospf6->router-id.

ospf6->router-id can change in the following conditions:

- A configuration change provides a new router-id value according to
  the above rules. ospf6->router-id is updated to the new value if
  there is no adjacency in FULL state. Otherwise, the ospf6d process
  must be restarted to take the new router-id into account.
- On startup of both zebra and ospf6d, if ospf6d has not yet received a
  valid router-id, ospf6d->router-id is set to 0 (i.e. 0.0.0.0). Then,
  zebra notifies ospf6d that the router-id is available.

At ospf6->router-id, the current behavior of ospf6d is the following:

- The self generated LSAs that refer to the previous router-id as the
  advertising router are kept.
- Self generated LSAs are created with router-id value.
- LSAs from the redistribution that refer to the previous router-id are
  kept and no new redistribution LSAs are created.

As a consequence, the routers in the ospf6 areas will get incorrect
LSAs and might not be able to install prefixes of those LSAs into their
RIB.

This fix solves this issue by resetting the areas and the redistribution
when ospf6->router-id updated.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>