ChronoSync

Reset interest should be propagated to all participants in a sync group. However, a data packet that is cached in the network may prevent the reset interest from being further propagated.

One solution could be assigning a unique name to each reset interest.
However, this solution may prevent reset interest to be merged in the network, thus an end user may receive a lot of reset interests.

Another solution to this problem could be using implicit digest. The idea is like this:
Ideally, there should not be any response to a reset interest, but if there is a response, the response should be exactly as what the end user requires to be.
In this case, the response should have 0 FreshnessPeriod, which means the response should not be cached in the network.
Therefore, the end user, before sending a reset interest, should construct the expected response and calculate the digest of the response.
The reset interest must carry the digest as the implicit digest.
As a result, the end user either does not receive any response or receive a response with FreshnessPeriod 0.

An reset data packet should look like this:

Name: /<sync_group_sync_prefix>/reset/[round_num] / (implicit_digest)
MetaInfo: FreshnessPeriod = 0
Content: (empty)
Signature: Digest_SHA256

The round_num indicates how many reset rounds has been done. See more details in issue #2076.

Note: we could use double hash function to avoid collision.