v2.0: chore: bump curve25519-dalek from 3.2.1 to 4.1.3 (backport of #2252)

[mergify]

Problem

we did this bump in #1693, but it seems like we have some concerns that broke the semver convention. I revered it in #2055.

Summary of Changes

try to bump it again

---

This is an automatic backport of pull request #2252 done by Mergify.

[mergify]

Cherry-pick of 6e23e69 has failed:

On branch mergify/bp/v2.0/pr-2252
Your branch is up to date with 'origin/v2.0'.

You are currently cherry-picking commit 6e23e69f09.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   .github/scripts/downstream-project-spl-common.sh
	modified:   curves/curve25519/src/edwards.rs
	modified:   curves/curve25519/src/ristretto.rs
	modified:   curves/curve25519/src/scalar.rs
	modified:   perf/src/sigverify.rs
	modified:   sdk/program/src/pubkey.rs
	modified:   zk-sdk/Cargo.toml
	modified:   zk-sdk/src/encryption/elgamal.rs
	modified:   zk-sdk/src/encryption/pedersen.rs
	modified:   zk-sdk/src/range_proof/generators.rs
	modified:   zk-sdk/src/range_proof/inner_product.rs
	modified:   zk-sdk/src/range_proof/mod.rs
	modified:   zk-sdk/src/range_proof/util.rs
	modified:   zk-sdk/src/sigma_proofs/ciphertext_ciphertext_equality.rs
	modified:   zk-sdk/src/sigma_proofs/ciphertext_commitment_equality.rs
	modified:   zk-sdk/src/sigma_proofs/grouped_ciphertext_validity/handles_2.rs
	modified:   zk-sdk/src/sigma_proofs/grouped_ciphertext_validity/handles_3.rs
	modified:   zk-sdk/src/sigma_proofs/mod.rs
	modified:   zk-sdk/src/sigma_proofs/percentage_with_cap.rs
	modified:   zk-sdk/src/sigma_proofs/pubkey_validity.rs
	modified:   zk-sdk/src/sigma_proofs/zero_ciphertext.rs
	modified:   zk-token-sdk/Cargo.toml
	modified:   zk-token-sdk/src/encryption/elgamal.rs
	modified:   zk-token-sdk/src/encryption/pedersen.rs
	modified:   zk-token-sdk/src/instruction/zero_balance.rs
	modified:   zk-token-sdk/src/range_proof/generators.rs
	modified:   zk-token-sdk/src/range_proof/inner_product.rs
	modified:   zk-token-sdk/src/range_proof/mod.rs
	modified:   zk-token-sdk/src/range_proof/util.rs
	modified:   zk-token-sdk/src/sigma_proofs/ciphertext_ciphertext_equality_proof.rs
	modified:   zk-token-sdk/src/sigma_proofs/ciphertext_commitment_equality_proof.rs
	modified:   zk-token-sdk/src/sigma_proofs/fee_proof.rs
	modified:   zk-token-sdk/src/sigma_proofs/grouped_ciphertext_validity_proof/handles_2.rs
	modified:   zk-token-sdk/src/sigma_proofs/grouped_ciphertext_validity_proof/handles_3.rs
	modified:   zk-token-sdk/src/sigma_proofs/mod.rs
	modified:   zk-token-sdk/src/sigma_proofs/pubkey_proof.rs
	modified:   zk-token-sdk/src/sigma_proofs/zero_balance_proof.rs

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   Cargo.lock
	both modified:   Cargo.toml
	both modified:   programs/sbf/Cargo.lock

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[t-nelson]

why do we need to bump major on a dependency in beta?

[samkim-crypto]

Backporting the dalek crate made sense a couple months ago, but given that 2.0 will hit mainnet in a little over a month, I think it makes sense to just include the version bump in 2.1.

[yihau]

@joncinque looks like the mainnet-beta will switch to v2.0 soon. do we still want to backport this one 🤔

[joncinque]

@joncinque looks like the mainnet-beta will switch to v2.0 soon. do we still want to backport this one 🤔

Yeah, let's hold off on this backport. We should call out the breaking change in the 2.1 changelog though, since we have a breaking change between 2.0 and 2.1 🫠