txnbuild: update challenge tx helpers for SEP-10 v1.3.0

Question

PR Checklist ### PR Structure * [x] This PR has reasonably narrow scope (if not, break it down into smaller PRs). * [x] This PR avoids mixing refactoring changes with feature changes (split into two PRs otherwise). * [x] This PR's title starts with name of package that is most changed in the PR, ex. `services/friendbot`, or `all` or `doc` if the changes are broad or impact many packages. ### Thoroughness * [x] This PR adds tests for the most critical parts of the new functionality or fixes. * [x] ~I've updated any docs ([developer docs](https://www.stellar.org/developers/reference/), `.md` files, etc... affected by this change). Take a look in the `docs` folder for a given service, like [this one](https://github.com/stellar/go/tree/master/services/horizon/internal/docs).~ ### Release planning * [ ] I've updated the relevant CHANGELOG ([here](services/horizon/CHANGELOG.md) for Horizon) if needed with deprecations, added features, breaking changes, and DB schema changes. * [x] I've decided if this PR requires a new major/minor version according to [semver](https://semver.org/), or if it's mainly a patch change. The PR is targeted at the next release branch if it's not a patch change.

What

Add new challenge transactions helpers to txnbuild to support verifying a challenge transaction that has multiple signatures. Add three new functions:

• ReadChallengeTx: Read the details like the transaction and the client account ID out of the transaction.
• VerifyChallengeTxSigners: Verify that the signers of the transaction are a subset of a list of signers given to the function.
• VerifyChallengeTxThreshold: Verify that the signers of the transaction are a subset of a list of signers that meet a required threshold.

Deprecate VerifyChallengeTx.

Why

The SEP-10 change that is open in stellar/stellar-protocol#489 clarifies how an implementer should verify that signers of the transaction are signers on the account and that accounts may have multiple signers.

An implementer needs to read out of the transaction the client account before verifying the transaction. For this reason we need two functions, one to read out details we need before verification and one to perform verification.

The read call also validates the server signature because no challenge transaction would ever be valid to read if it wasn't signed by the server.

Known limitations

These helper functions take a decent amount of complexity away from an implementer, but they still leave a decent amount up to the implementer. An implementer would still need to make a call to Horizon. I think it might be out-of-scope of the txnbuild package to offer that additional logic and SEP-10 technically leaves the exact details of what happens there up to the implementer so it would also be difficult to implementer in a library function.

该提问来源于开源项目：stellar/go

Answer 1

provided some feedback to me directly that we need to be able to offer this as a similar level of drop-in as the prior functions that support SEP-10. In light of this I think I'm going to move the functions I'm adding out of txnbuild and into a new package, maybe called webauth or challenge or txnchallenge, and then explore how to offer verification using a configurable strategy, while providing some default strategies for popular use cases like anchors.