lease6-update and v6 BLQ tables in memfile

There is an issue created by new BLQ tables and lease6-update (and lease6-bulk-apply too).

Currently the v6 BLQ tables in memfile (they will be implemented too in other backends and for v4 but this does not change the point) are updated on delete, add operations but the update operation is different mainly because in some cases we want to keep the current extended info from the "old" lease vs from the "new" lease. This is handled by the allocation engine through an action parameter passed in a new member of the (new) lease (another solution would be to add a parameter to updateLease6 but again it does not change the point).

The 3 possible actions are:

• ACTION_IGNORE i.e. ignore the user context of the new lease (used to keep the "old" extended info)
• ACTION_DELETE i.e. delete all entries for the lease address from tables (used for instance when reclaiming a lease)
• ACTION_UPDATE i.e. first delete all entries, decode the "new" extended info and if there is one adds it to tables

The default is ACTION_IGNORE but it does not make a lot of sense for lease6-update as tables are rebuilt at memfile reload: to summary if someone does not want to take into account the extended info in lease6-update the safe way is to remove it from the lease before calling updateLease6.

So the right action should be ACTION_UPDATE so the extended info is transmitted to the server executing lease6-update. It is far to be optimal when the "old" lease has the same extended info but lease6-update and lease6-bulk-apply call a shared routine named addOrUpdate6 which begins by a getLease6 on the type and address so the "old" lease is available and it is enough to ignore when the extended info does not change as updateLease6ExtendedInfo does.