Test behavior for initial accounts when "attempting" to generate ZK proofs and verify proofs

[DOBEN]

Task description

The first version of the identity infrastructure on Concordium had the identity providers deploy an Initial account on behalf of the users. Further iterations moved the deployment process to the user to preserve privacy (the identity providers won't know the account addresses of the users anymore). Identity providers now only verify the identity and sign a corresponding identity object which is returned to the user's wallet before a Pedersen commitment is deployed by the user (based on the identity object) on-chain whenever creating an account.

So far we have been excluding these initial accounts from any service doing ZK proof verification.
https://github.com/Concordium/concordium-dapp-examples/blob/e34d1a55e92bb912695147f9561afe4af6af2620/compliant-reward-distribution/indexer-and-server/src/bin/server.rs#L397
In addition, since Initial accounts most likely lived in legacy file-based wallets (without ZK proof generation support), it was practically unlikely that anyone would generate a proof.

Currently, there are discussions to consolidate the legacy file-based wallet into our current wallet and make the legacy wallet unavailable. As such it could happen that file-based wallets (with Initial accounts) are in a wallet one day that supports ZK proof generation. As such, we want to investigate/test if that case is handled gracefully:

Sub-tasks

• "Attempting" to verify a ZK proof for an initial account:
  https://github.com/Concordium/concordium-dapp-examples/blob/e34d1a55e92bb912695147f9561afe4af6af2620/compliant-reward-distribution/indexer-and-server/src/bin/server.rs#L262

[Radiokot]

Currently, when a file wallet user tries to initiate a WalletConnect verifiable presentation request in CryptoX, they get this error: Only seed phrase wallets support this feature and the request is being rejected.

[DOBEN]

Great @Radiokot: I removed the subtask about testing the wallets.

For the remaining subtask:
The following two proofs generated would be interesting to see the behavior when being verified:

1. Test: Generate a normal proof with another account and then replace the "accountAddress (meaning the cred_id)" with the "initialAccount". See picture:

To look up the cred_id of an account use:

concordium-client account show 3cGEB7tTdQBFxJ9sn5JyGPNay2MSmRSKm4133UVqmKoFg4MXJ1 --grpc-port 20000 --grpc-ip grpc.testnet.concordium.com --secure

2. Test: Pick a random elliptic curve point (as the missing pedersen commitment); generate a proof for the "initial account" assuming it has this pedersen commitment.

Which initial account do we have for testing (Great input from @tschudid)?
We are not aware of controlling such an account on testnet but we can search for one deployed (by someone). Because we don't have to control (know the private key) for testing just the ZK proof generation when picking our own random pedersen commitment.