Session ids should be something other than raw increments in payjoin-cli

[benalleng]

coming from #1558 (comment)

This references the liana integration where a review comment asked what would happen if a wallet was imported and tried to start a payjoin session where there were already existing payjoins. Would this cause an overlap or an error?

While we generally reference the session Id when creating a new payjoin session incrementing does cause a problem when both sender and receiver are treated separately such that this is what the history looks like.

Session ID   Sender/Receiver           Completed At    Status         
1            Sender                    Not Completed   Session expired at Time(Time(1780413414))
2            Sender                    1780327516      Session expired at Time(Time(1780413866))
1            Receiver                  Not Completed   Waiting for original proposal
2            Receiver                  Not Completed   Waiting for original proposal

The following command will be unable to resolve

payjoin-cli cancel 1

You will receive and error like so.

Error: Session 1 exists as both a sender and receiver session. Pass `--role sender` or `--role receiver`.

It seems like better UX to simply create random or timestamp based session ids to hold internally to better manage these individual sessions.

[DanGould]

timestamp really seems like the move here. Second precision seems sufficient for payjoin-cli, but it's got me wondering if it's sufficient as a reference for services that rely on higher frequency transactions and how we'd address id for them.

[benalleng]

https://docs.rs/crate/uuid/1.23.3/source/src/v7.rs#17

Time based uuid? Its already in payjoin-cli's dep tree