represent whether signed and/or proven within Transaction type + rework prove method

[harrysolovay]

Closes #1514

Updates the Transaction and TransactionPromise types with two type params Proven extends boolean and Signed extends boolean. This enables us to do the following.

1. conditionally include/exclude members based on stage of method chaining.

const a = Mina.transaction(sender, async () => {
  await zkapp.increment()
})
a satisfies TransactionPromise<false, false>
a.prove // exists
a.sign // exists
a.proofs // does not yet exist

const b = a.prove()
b satisfies TransactionPromise<true, false>
b.prove // no longer exists
b.sign // exists
b.proofs // now exists

const c = b.sign([senderKey])
c satisfies TransactionPromise<true, true>
c.prove // does not exist
b.sign // no longer exists
b.proofs // exists

2. Constrain transaction-accepting methods based on the transaction stage.

declare function acceptsSignedTxsOnly(transaction: Transaction<boolean, true>): void

---

An additional change that was needed to make this possible: the prove method no longer directly returns the proofs, but rather a Transaction<true, Signed>, where true is the boolean type param representing whether the transaction has been proven. TransactionPromise has a corresponding prove method, which produces a TransactionPromise<Signed, true>.

In order to access the actual proofs, one can utilize the proofs method of a given Transaction<true, boolean> or TransactionPromise<true, boolean>.

const proofs = await Mina.transaction(sender, async () => {
  await zkapp.increment();
})
  .sign([...keys])
  .prove()
  .proofs();

proofs; // `(Proof<ZkappPublicInput, undefined> | undefined)[]`

[mitschabaude]

@harrysolovay it would be nice if you added an entry about all of the new chaining methods in CHANGELOG.md

The prove() change in particular belongs under breaking changes because .prove() returns the proofs in a different format now

[harrysolovay]

it would be nice if you added an entry about all of the new chaining methods in CHANGELOG.md

Given that the changelog is part of the codebase, the commit range would be self-referential. I'm not sure what the o1js workflow is for including this range. Any guidance for where to / how to set up the contents for the next changelog?

[mitschabaude]

Given that the changelog is part of the codebase, the commit range would be self-referential.

Don't change any commit range - just include a bullet point with your change and a link to this PR

[mitschabaude]

Hey @harrysolovay, as a next step it would be nice to merge main, so that we can run the ci pipeline again

[harrysolovay]

@MartinMinkov thank you for getting this passed the finish line!