Handle absence of ValueState about akd

[afterdusk]

There's two parts to this:

1. Stale ValueStates

Clearing stale ValueStates helps avoid retaining information in storage that is no longer required for operation of the underlying service. In the example of end-to-end encrypted messaging, this would correspond to outdated Identity keys. The library is already able to handle such deletions and can continue to operate as long as the most recent ValueState for a user is present.

2. Non-Stale ValueStates

Non-stale (i.e. most up-to-date) ValueStates will need to be deleted when users leave the underlying service. In the E2EE messaging scenario, this corresponds to the messenger service deleting a user's most recent identity keys when they delete their account.

While AKD is able to continue to operate when these states are deleted, the problem arises when a user with the same label re-joins the service. When next publishing for the user, AKD will be unable to deduce the next version number to use, given that all previous ValueStates have been deleted. Furthermore, it's not clear if the new user should share the same series of version numbers as the previous user, even if their labels are the same. In the E2EE messaging context, a new user could be the new owner of a number (and therefore label), but an entirely different person from the previous owner of the number.

[slawlor]

For 2) I think that we could deduce the version number, in the event a node exists but there is no value states, by simply enumerating the child states of the node. N+1 would be the new version number, and we could move forward as such.

[slawlor]

Should not have closed with #161 (magic words)