DHCPV6_RENEW gets old lease even if new address is reserved for the client

Replication steps:

1. Configure this:

"reservations-global": True,
"reservations-in-subnet": True,
"reservations-out-of-pool": False

2. Use subnet commands to add a subnet with a pool.

{
  "command": "subnet6-add",
  "arguments": {
    "subnet6": [
      {
        "id": 1,
        "interface": "$(SERVER_IFACE)",
        "pools": [
          {
            "pool": "2001:db8:a::50-2001:db8:a::50"
          }
        ],
        "subnet": "2001:db8:a::/64"
      }
    ]
  }
}

3. Let a client do a SARR and get a lease from the pool.
4. Use host commands to reserve an address matching the same client by DUID. I don't think it matters if the reservation is global or in-subnet. I tested with global.

{
  "command": "reservation-add",
  "arguments": {
    "reservation": {
      "subnet-id": 0,
      "duid": "00:03:00:01:f6:f5:f4:f3:f2:01",
      "ip-addresses": [
        "2001:db8:a::100"
      ]
    }
  }
}

5. Wait for the client to send a renew.
6. See that the client got the old address 2001:db8:a::50 instead of the reserved address 2001:db8:a::100.

Expected behavior: the client should be forced to get the reserved address. I guess that would mean no reply or a DHCPV6_REPLY without a IA_NA.

The general rule I'm trying to respect is: changes to configuration should have an impact on the client immediately or in the close future without expecting the client to go through some specific scenario.

• This doesn't happen if the client sends a complete SARR again.

• This doesn't seem to happen in v4 if DHCPREQUESTs are sent instead of DHCPV6_REPLY. But I may have not simulated the v4 renew scenario well enough to reproduce it.

These forge tests fail:

• FAILED tests/dhcpv6/kea_only/host_cmds/test_hosts_cmds.py::test_v6_hosts_cmds_global_to_in_subnet[False-MySQL]
• FAILED tests/dhcpv6/kea_only/host_cmds/test_hosts_cmds.py::test_v6_hosts_cmds_global_to_in_subnet[False-PostgreSQL]