Remove requestId/sessions, leave to integrators, encode sessions in payment pointers

[sublimator]

Is there actually any need for a requestId ? It was used for unlocking content (in general tracking a session balance) before receipts were added. The requestId is sent in the headers of the SPSP request as Web-Monetization-Id. The latest version of the spec actually denotes it as deprecated.

So in the next version, will it be removed ?

This question came to me when trying to get my head around the new "idle" | "interactive" states. A big part of the requirement for pending/start/stop events is the need to show when the requestId changed. It's a definition of what is starting/stopping etc. The "session" matching that requestId.

Questions:

• Could receipts replace it adequately? I think in many contexts it's useful when you can provide your own unique ID (@justmoon )
• I need to check if the Uphold or Gatehub payment pointer implementations are listening for it. (@AlexLakatos )

Notes:

• With our (Coil) experiments with jamming in tipping (backend doing the sending of tips, rather than the extension) into progress events, we found that the states/events became a bit awkward.
• Our experiments with batch payments showed that receipts aren't so useful for tracking a balance if they aren't submitted ( Imagine a "post pay" scenario where a user closes a tab, and the browser does a catch up payment: the progress handler submitting receipts doesn't get a chance to run). And of course the receipt nonce/id changes upon reconnect. @sharafian proposed encoding the session ids into the payment pointers themselves to handle this.
• In the Coil extension internally we use the requestId as the stream id

[AlexLakatos]

I need to check if the Uphold or Gatehub payment pointer implementations are listening for it. (@AlexLakatos )

Confirmed with @sharafian, wallets aren't listening for it.

Ben also agrees we can go ahead and remove the requestId.