Add a function to help `TransactionModifyingSigner` update `lifetimeConstraint`

[mcintyre94]

Our API for TransactionModifyingSigner requires a lifetime to be returned:

    modifyAndSignTransactions(
        transactions: readonly (Transaction | (Transaction & TransactionWithLifetime))[],
        config?: TransactionModifyingSignerConfig,
    ): Promise<readonly (Transaction & TransactionWithinSizeLimit & TransactionWithLifetime)[]>;

As such a signer can modify the transaction, this lifetime may be different from the input one. Identifying the lifetime constraint requires decompiling the transaction and inspecting its first instruction (whether it's advance nonce determines if the token is a blockhash or nonce), so should be avoided if possible.

We have code to help with this in the react useWalletAccountTransactionSigner hook:

kit/packages/react/src/useWalletAccountTransactionSigner.ts

Line 97 in 874a02f

const existingLifetime =

And this is also used in the PR to add non-react WalletAccount -> Signer functions: #1368

This code is useful for anybody writing a similar TransactionModifyingSigner. We could extract it to a helper in the transactions package to make it easier for others to write similar signers.

[dpsi9]

Quick question before implementing this, In the previous discussion, two approaches were mentioned reconstructEncodedTransactionFromOriginalTransaction(originalTransaction, encodedTransaction) and hasTransactionLifetimeChanged(originalLifetime, messageBytes). Which one should I go with(imo first one looks right).
And also, where should this function live in the transaction package? in a separate file(eg - resolve-transaction-lifetime-constraint.ts) or added to an existing lifetime.ts file.

[mcintyre94]

I'd lean toward the first as well, but it probably won't be super clear until we start refactoring the code (I'd suggest using your current PR as the starting point) what the best API looks like here. I think hopefully when we're using this in the function from your PR (and maybe this time worth refactoring the react one at the same time to validate the API), we'll have a good idea exactly what makes sense to extract.

I'd suggest a new file in the transactions package