Use consumers for identities (instead of sufficients) so identities cannot bypass existential deposit

Context
Today, identity ownership has historically relied on frame_system sufficients references. A sufficient reference allows an account to stay alive without requiring a provider-backed existential deposit (ED).

Problem
This behavior allows identity accounts to survive without truly meeting the normal account liveness rules. In practice, an identity account can get special persistence semantics that differ from the intended runtime policy.

We want identity accounts to follow standard account economics: an existing identity should still require an account that respects existential deposit constraints.

Why this change
Switching identity lifecycle references from sufficients to consumers makes identity persistence depend on normal provider/account rules instead of “self-sufficient” survival. This prevents identities from implicitly bypassing ED expectations.

Proposed change

  1. On identity creation, increment consumers (not sufficients).
  2. On identity deletion/removal, decrement consumers for new identities.
  3. Keep backward-compatible handling for legacy identities still carrying sufficients: decrement sufficients when present.
  4. In owner-key change flows, clean up old keys with the same legacy/new split (sufficients first if present, otherwise consumers).

Expected outcome

  • Identity-linked accounts no longer rely on sufficient references for persistence.
  • Existing identities must effectively satisfy normal account existence constraints (including ED-related behavior).
  • Legacy identities continue to be handled safely during transition.

Acceptance criteria

  • New identities do not increase sufficients.
  • New identities cannot be fully drained with transfer_all; ED remains.
  • Legacy identities are removable/key-change-safe without refcount underflow or leaks.
  • Integration test added for “identity cannot transfer all funds to zero balance.”
Edited by Éloïs