Stabilize transactionWatch to version 1

[lexnv]

This PR stabilizes the following methods:

• transactionWatch_unstable_submitAndWatch -> transactionWatch_v1_submitAndWatch
• transactionWatch_unstable_unwatch -> transactionWatch_v1_unwatch

Opened this PR to discuss the best path forward for transactionWatch.
We had different views about this method class on #139, and would love to get your feedback on this 🙏

cc @paritytech/subxt-team @tomaka @josepot

[jsdw]

My views from the other places lean in favour of stabilising this.

I think that it's good to expose such a method for when people just want to submit a TX in relative isolation. When we want to coordinate with chainHead_follow we have transaction_v1_broadcast, which plays more nicely with chainHead_follow.

While having a higher level API like Subxt/PAPI on top is recommended, I'd prefer that one could also talk directly with these JSON-RPC methods to accomplish things. Without transactionWatch, submitting a transaction and waiting for its inclusion/error feels a bit out of reach without such a higher level API on top (you need to use/understand chainHead_follow, make runtime calls to validate the TX, ask for and download potentially megabytes of block bodies and then understand how to decode those bodies, search for the tx and hash it appropriately to compare, and know when to stop searching for it in case of error (ie revalidate it periodically)).

My final thought is that this function is in a separate group from others and new light clients etc could simply opt not to implement it if it is too much effort for them.

My only reason against this method existing is that we do already have another means of submitting transactions, and so there is a part of me that does not like the fact that there are now two ways of doing something.

[tomaka]

For what it's worth, since smoldot is backwards-compatible with the author_submitAndWatch function of the legacy API, implementing transactionWatch is very straight-forward and doesn't add much code.
Of course, in the future, smoldot could drop support for both of them at the same time.

[lexnv]

We'll plan to merge this PR in the next few days (prob Monday) if there are no further objections.

Ideall #146 should get merged first

[tomaka]

It would have been appreciated to not merge #146 (which modifies the API) and this PR together. The point of stabilizing is to finalize a specific API. Modifying the API right before stabilizing it isn't great.

[jsdw]

Sorry about that @tomaka! i'd forgotten that you were on holiday and had taken the lack of repsonse to mean there were no objections :)