solana: Add set_threshold ix

[nvsriram]

Currently there is no way to update the NTT manager threshold (# of transceivers that must attest to a transfer before it is accepted) - it defaults to 1 - or deregister a transceiver. With multi-transceiver support, having a way to manage transceivers and their threshold is essential.

This PR adds:

• set_threshold ix to update the threshold (0 < threshold <= # of enabled transceivers)
• deregister_transceiver ix to deregister (disable transceiver in enabled transceiver bitmap):
  • Also decrements threshold (down to minimum 1) if # of enabled transceivers < threshold
• Update register_transceiver ix to also act as re-enable:
  • If RegisteredTransceiver account is init for the first time, assign new id
  • Otherwise, reuse old id
• Rust tests to verify edge cases
• createSetThresholdInstruction and createDeregisterTransceiverIx TS helpers as a part of NTT namespace and SolanaNtt class respectively
• Update IDL

[nonergodic]

I also now realize why I felt confused:
Enabled transceivers suggests that there can be such a thing as a disabled transceiver. But really, there are only registered transceivers, so the naming is suboptimal.

The deregister function makes it seem like you just want to recoup rent, but really it's primarily about disabling the transceiver.

[kcsongor]

overall the changes look good, but a couple of comments:

• on the EVM side, we don't support deregistering transceivers, only disabling them. We should consider doing the same here. the rent saving is marginal here (given the frequency of this operation), and it might be good to be able to re-enable a transceiver (re-registering it will give it a new id).
• I think we shouldn't modify the threshold when disabling a transceiver. arguably the contract should be paused when modifying transceiver/threshold configurations, but if it's not, then as the admin modifies the config, there will be temporary scenarios where less than the intended threshold of transceivers can attest a message

[nvsriram]

• on the EVM side, we don't support deregistering transceivers, only disabling them. We should consider doing the same here. the rent saving is marginal here (given the frequency of this operation), and it might be good to be able to re-enable a transceiver (re-registering it will give it a new id).

Are you suggesting a reenable_transceiver instruction or updating register_transceiver to double as reenable?

Currently, register is defined with init. To make it so we can re-enable, it would be init_if_needed. Similarly, I'd have to handle the cases depending on whether it is initialized or not to avoid updating its id.

[nvsriram]

• I think we shouldn't modify the threshold when disabling a transceiver. arguably the contract should be paused when modifying transceiver/threshold configurations, but if it's not, then as the admin modifies the config, there will be temporary scenarios where less than the intended threshold of transceivers can attest a message

This is what EVM does (decrement threshold if too high) so it is mostly just lifted from there.

I agree that disabling could be limited to when contract is paused so could add a constraint for that.
However, say the owner pauses, deregisters a transceiver but threshold is not updated. Then they unpause and transfer, it will still go through as there is no ThresholdTooHigh check...