First rewrite of the uSubscription spec

[AnotherDaniel]

Restructuring and partial rewrite of this spec; specific focus on:

• more detailed explanations of concepts like remote subscriptions
• migrate diagrams into embedded mermaid
• add OFT-style requirements markers

[sophokles73]

@AnotherDaniel are you still working on this? IMHO it would be great, if these changes could make it into 1.6.0 ...

[AnotherDaniel]

Yes, still on it, or rather back on it after many weeks of "distractions"... let me see where I've left this...

[sophokles73]

@AnotherDaniel it is very, very hard to keep track of the changes when you force push changes, because it removes all of my original comments from the diff view :-(

[AnotherDaniel]

Sorry for that - I rebased on current main, didn't realise that would break the diff view. Won't do that again.

Essentially, I accepted all your suggestions, plus I pulled in new requirements to cover all methods from the usubscription.proto definition, new ones to be found in the "Subscription" and "Reset" sections.

[sophokles73]

I have made some comments on the Subscribe operation which should also apply to the other operations accordingly.
In general, the spec item IDs should probably better contain usubscription instead of usubscribe, e.g. dsn~usubscription-... instead of dsn~usubscribe-....

[AnotherDaniel]

Let me know if you're reasonably happy with this iteration, then I'll squash the commits to prep for merge.

[sophokles73]

I still do not see any value in splitting up the different types of invalid topic UUris ... my proposal could be applied to all operation specs.
But if you feel that this is necessary, then please go ahead and merge.

[sophokles73]

LGTM

[stevenhartley]

A number of comments.

[AnotherDaniel]

Many small and medium changes to address review feedback. Pls have another look @stevenhartley and @sophokles73

[sophokles73]

LGTM

[sophokles73]

@stevenhartley would you mind taking another look? Your approval is required before we can merge this PR ...

[stevenhartley]

@AnotherDaniel , I don't understand why the sequence diagrams shows another lifeline for the SubscriptionChange, this notification is sent to the uApp so it is clearer if you show a different line type to mean notification vs RPC as it is a message sent to uApp (per the old diagrams). Also the colors are hard to see in dark mode (the lines are grey), I think you can set the line color to be black.

[stevenhartley]

Please also rebase as you seem to have accidentally pulled in other things on main on this PR

[stevenhartley]

Last comment @AnotherDaniel , can you add a legend that explains the arrows (ex. this is a RPC request vs response, vs publish, vs notification)? Thank you

[stevenhartley]

LGTM! Thanks for your patience @AnotherDaniel

[AnotherDaniel]

Yay, this was a long time coming! ;-)