Inconsistent statistics of declined and assigned leases

This issue is a direct result of investigating the following Stork issue: stork#1481 (closed)

Even though the bug reporter uses the old Kea 2.2 version, the problem still seem to still exist in the latest versions. I wrote a simple unit test verifying the following scenario:

• Enable lease affinity.
• Have a client that acquires a lease using normal 4-way exchange.
• Remember the allocated address.
• Check that the assigned-leases stat is 1 and the declined-leases stat is 0.
• Use the client to release the lease. The lease should remain in the database in the released state.
• Check that the assigned-leases stat is 0 and the declined-leases stat is 0.
• Use the remembered address and the client to send a DHCPDECLINE to the server for this address.
• Check that the assigned-leases stat is still 0 and the declined-leases stat is 1.

This behavior violates the last paragraph of the following Kea ARM chapter: https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#duplicate-addresses-dhcpdecline-support

It is expected that the assigned-leases statistics includes both valid and declined leases. This is the case in the typical scenario when a client performs the 4-way exchange and sends the DHCPDECLINE right after the DHCPACK. The lease affinity opens the door to the server receiving the DHCPDECLINE after the lease was released or reclaimed. Note that the lease reclamation can have the same effect in certain cases.

In my opinion the expected behavior here is that the server refuses to decline an expired or released lease. Such a lease no longer belongs to the client. Note that the code checks if the lease belongs to the client before declining it but this check is merely restricted to the client-id and/or hw-address.