Fix GXS identity validation for pre-0.6.8 identities by reconstructing legacy mServiceString used at signing time

[jolavillette]

Fix GXS identity validation for pre-0.6.8 identities by reconstructing legacy mServiceString used at signing time

Fix "Not found" identities from pre-0.6.8 nodes

Since commit c5135a2, mServiceString is excluded from the serialized payload (replaced by ""). However, service_CreateGroup() in p3idservice populates mServiceString before createGroup() computes the admin signature. This means all pre-0.6.8 identities were signed with a non-empty mServiceString, and strict admin validation (d82c7b5) now rejects them all.

Fix: After the standard verification fails, reconstruct the deterministic mServiceString that was present at identity creation time and retry signature verification. Three candidates are tried:

The mServiceString received from the network (covers edited identities)
The default anonymous creation string ("v2 {P:K:0 T:0 C:0}{T:F:0 P:0 T:0}{R:5 5 0 0}")
The default PGP-linked creation string (PGP ID extracted from received data)
Every candidate is fully verified cryptographically — no security exception is introduced. New identities continue to be signed with "" as intended.

Known limitations: The fallback may still fail for identities that were edited on 0.6.7 after mServiceString was locally modified by the service (e.g. reputation score change), and then forwarded through an intermediate node that overwrote mServiceString with its own local values. In that case the original signed data is irrecoverable. The fix also requires the PGP ID to still be present in the received mServiceString for PGP-linked identities.

[zapek]

Validating groups is already a burden. You really want to multiply it by 3?

[csoler]

I understand the motivation for attempting to add backward compatibility, but this complicates the signature verification far too much and thereby increases the attack surface. I really think we shouldn't go that way.