Add previous_in_topic field to all certificates schemas

[touilleMan]

Questions:

• Shamir currently has a single topic depending on the receiver (so a given certificate's previous in topic certificate will be different depending on who is asking for certificates in this topic !)
  • Replace this field by previous_shamir_for_this_user ?
  • Introduce per user-to-recover topic for shamir ?
• User&Device redacted should use the previous redacted certificate fort this field ?
  (most likely yes, as otherwise the client cannot check this field, but then what to do with UserCertificate::redacted_compare() ?)

[AureliaDolo]

This would be nice to have for the shamir deletion certificates ✨ #7609

[AureliaDolo]

We could use previous in timestamp as a opaque identifier and for certificates that are not related to the given user could be redacted, showing only an id and the previous one.

Also, from what I understand, for any given shamir setup the brief and share will have the same timestamp and could be considered as a unit.

So we could either use

• a concatenation of the previous (brief and shares) digest as the the previous is topic for the next (brief and shares)
• or the previous brief only for the next brief, the share having either no previous in topic as they make no sense in isolation, or having their corresponding brief as a previous in topic.

I'd rather do the first option.

After #7609 there will be deletion certificates in between.

For the per user-to-recover topic, we're going to check every topic anyway to make sure that the user is not a share recipient somewhere.

And for the previous_shamir_for_this_user field, how does that interact with share recipients have access to both their share and the brief ?

[touilleMan]

Parsec v3 compatibility breakage is over, the ship has sailed without this feature.