Add receiver builder

[arminsabouri]

The initial typestate has always been an odd case. Stricly speaking you shouldn't be able to resume to an uninitialized state. The earliest state you can resume from is Initialized. So this commit removes UnInitialized as a "state" and replaces create_session with a builder model.

---

Note that Uninitialized is still a variant on the RecevierSession which represents a state before any events have been applied. I think there is value to removing the Uninitialized variant as applications have to still match on it when resuming. Instead we could have pub(crate)'d struct method serving the same purpose. Where the private struct method can only process the first event and return the RecevierSession sum type.
Cherry picked off #995

Pull Request Checklist

Please confirm the following before requesting review:

• A human has reviewed every single line of this code before opening the PR (no auto-generated, unreviewed LLM/robot submissions).
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 17304182660

Details

• 40 of 43 (93.02%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.008%) to 85.78%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
payjoin/src/core/receive/v2/mod.rs	37	40	92.5%

Totals
Change from base Build 17301530031:	0.008%
Covered Lines:	8041
Relevant Lines:	9374

---

💛 - Coveralls

[DanGould]

I dig the first commit (which passes tests)

The second one I think is more complicated than having a simple Uninitialized state (+26 -9). The empty Uninitialized state seems good enough for sender and I'd rather leave it for the receiver too. ReceiverBuilder design LGTM. I just ask that it's build is chained where possible and not assigned unless it needs to be in one case.

[DanGould]

I think let session = ReceiverBuilder::new() ..build().save(&persister)?; All chained is the way to go

[DanGould]

If one of the states is to go, I think it's the Receiver<UninitializedReceiver> state rather than the SessionEvent::Uninitialized.

[DanGould]

The way to get rid of that Receiver<UninitializedReceiver> is by following the v2::SenderBuilder pattern and having the ReceiverBuilder create the actual receiver instead of only the event:

rust-payjoin/payjoin/src/core/send/v2/mod.rs

Lines 156 to 178 in bffb9b5

	pub fn build_non_incentivizing(
	self,
	min_fee_rate: FeeRate,
	) -> Result<NextStateTransition<SessionEvent, Sender<WithReplyKey>>, BuildSenderError> {
	let psbt_ctx = self
	.psbt_ctx_builder
	.build_non_incentivizing(min_fee_rate, self.output_substitution)?;
	Ok(Self::v2_transition_from_psbt_ctx(self.pj_param, psbt_ctx))
	}
	/// Helper function that takes a V1 sender build result and wraps it in a V2 Sender,
	/// returning the appropriate state transition.
	fn v2_transition_from_psbt_ctx(
	pj_param: PjParam,
	psbt_ctx: PsbtContext,
	) -> NextStateTransition<SessionEvent, Sender<WithReplyKey>> {
	let with_reply_key = WithReplyKey::new(pj_param, psbt_ctx);
	NextStateTransition::success(
	SessionEvent::CreatedReplyKey(with_reply_key.clone()),
	Sender { state: with_reply_key },
	)
	}
	}

[DanGould]

If you have a strong preference to only build the transition, then we should be changing the SenderBuilder to adopt the same pattern as the receiver once this goes in.

[DanGould]

utACK abfc6d3

This makes sense and mirrors SenderBuilder.

let's see about removing the ReceiveSession::Uninitialized (now with no contents) in a follow up along with SendSession to see if congruence makes sense.