add chain id

[zqhxuyuan]

Description

---

Before we can approve this PR for merge, please make sure that all the following items have been checked off:

• Connected to an issue with discussion and accepted design using zenhub "Connect issue" button below
• Added one label out of the L- group to this PR
• Added one or more labels from the A- and C- groups to this PR
• Explicitly labelled A-calamari, A-dolphin and/or A-manta if your changes are meant for/impact either of these (CI depends on it)
• Re-reviewed Files changed in the Github PR explorer.

Situational Notes:

• If adding functionality, write unit tests!
• If importing a new pallet, choose a proper module index for it, and allow it in BaseFilter. Ensure every extrinsic works from front-end. If there's corresponding tool, ensure both work for each other.
• If needed, update our Javascript/Typescript APIs. These APIs are officially used by exchanges or community developers.
• If modifying existing runtime storage items, make sure to implement storage migrations for the runtime and test them with try-runtime. This includes migrations inherited from upstream changes, and you can search the diffs for modifications of #[pallet::storage] items to check for any.

[github-actions]

⚠️ Congestion test: 1-day congestion cost (calamari) is NOT above target_daily_congestion_cost_kma

[ferrell-code]

I suppose it is more of a product decision whether we should accept any chain_id. This is fine on runtime side

[Garandor]

The BAB owner generates a ZKP, signs it from his BSC account and makes an SBT.
Now he gives the ZKP to a friend, who signs it from his ETH account and gets the same SBT (e.g. by manually calling the backend if the frontend doesn't allow him to).
prevented by the eip712 signature, so attacker must hold the corresponding private key

or

a fake frontend tricks the BAB owner into generating the ZKP and then provides a signature from some fake chain ID where the attacker controls the BAB owner's public address to steal the minted SBT from its owner.
You can add custom networks to metamask, so creating a fake chain like that which will provide a valid signature shouldn't be hard
Or even better, a fake chain that just send true on any signing request for any account.
prevented by it having to be a valid eip712 signature, so attacker must hold the corresponding private key

What makes this impossible?

maybe remove the admin setting, and only accept chain id as parameters, that will not cause any confuse?

i like this. the chain_info.chainid setting is meaningless in this case. just make the parameter non-Option