Remove ReceivedProposalPsbt infavor of session outcome

[arminsabouri]

The sender session is marked as successfully closed once the payjoin proposal is received. Currently, this state is recorded in a separate event (ReceivedProposalPsbt) from the Closed event which is inconsistent with the reciever implementation.

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 18727546149

Details

• 4 of 8 (50.0%) changed or added relevant lines in 3 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.003%) to 83.788%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
payjoin-cli/src/app/v2/mod.rs	0	2	0.0%
payjoin/src/core/send/v2/mod.rs	1	3	33.33%

Files with Coverage Reduction	New Missed Lines	%
payjoin-cli/src/app/v2/mod.rs	1	53.36%

Totals
Change from base Build 18694776764:	-0.003%
Covered Lines:	8977
Relevant Lines:	10714

---

💛 - Coveralls

[spacebear21]

I am not totally convinced that receiving the proposal and closing the session are the same event, couldn't there be a scenario where the proposal is received but the receiver broadcasted the fallback tx or double-spent their input, so the proposal tx is no longer valid?

[arminsabouri]

I am not totally convinced that receiving the proposal and closing the session are the same event, couldn't there be a scenario where the proposal is received but the receiver broadcasted the fallback tx or double-spent their input, so the proposal tx is no longer valid?

The sessions should close once there is no more expected payjoin activity -- for sender it would be receiving the proposal. Check out the rationale here #807 (comment)
Do you think the API should capture conflicting txs (i.e a monitoring typestate) and is that just for auditability/session history reasons?

[spacebear21]

code ACK - makes sense after re-reading the rational in #807. Maybe we should include that rationale in code comments for the sender and receiver closed events?