feat: allow sending webxdc update from broadcast subscribers

[r10s]

this PR allows channel subscribers send webxdc updates according to webxdc/website#137

the required webxdc info fields were already added at of #8138

closes #7679

[iequidoo]

So have you decided to not protect from "forwarding" subscribers' updates by the channel owner? Maybe confidentiality isn't a problem, but such forwarding may lead to bugs, see Hocuri's #7836 (review):

OTOH, it could be weird that the channel owner relays webxdc updates only if clicking "Resend" on the message; could lead to bugs.

[iequidoo]

Another problem is scalability: status updates acumulate over time, and the owner will resend all the status updates to new or even all the subscribers (if "Resend" is clicked). For broadcasts it will be worse than for groups, groups aren't large in general.

[r10s]

tbh, i was not aware or forgot there is a pr hanging around already :)

not resending updates at all, as in the old PR, will destroy many usecases of channels, so going for that seems to be over the top.

so options are to (1) resend everything, maybe fine, or (2) to not resend updates from subscribers somehow. main point for (2) i also see to avoid tricking the channel owner's app to do weird things because of bugs, and to have fewer updates in general, so scalability

[iequidoo]

I'd also go for (2), at least this way all subscribers will have the same set of status updates (i.e. owner's ones). My suggestion was to add a msgs_status_updates.from_id column for that. #7836 became complex because of struggling with status update resending, let's agree on some solution and close it then.

[r10s]

i try to sum up some discussion with @adbenitez @Amzd @link2xt - please add whatever i missed or remember wrong.

• as a general note, the idea of "this update belongs to someone" is not really matching the initial idea of webxdc. updates currently modify the states of an app and are visible for all

• from that point of view, it may be fine if updates get distributed, there was even the idea to always redistribute all updates

• that would make all existing apps work in broadcast channels without changes

• isBroadcast would not be needed at all (isAppSender would be sufficient to let owner behave differently)

BUT:

• redistributing may result in other large problems, related to traffic in large channels. and malfeasant subscribers may more eagerly try to trick apps than it is the case for webxdc

• related discussion was about the idea of accumulating updates, that may make the idea of redistribution easier, but is not easy in itself

as a summary, isBroadcast requires a different approach to write webxdc, resp. existing webxdc need adaption. maybe fine and what is expected.

there was no final agreement but that isAppSender makes sense as an interim step in any case

[iequidoo]

• as a general note, the idea of "this update belongs to someone" is not really matching the initial idea of webxdc. updates currently modify the states of an app and are visible for all

The idea wasn't "this update belongs or made by X", but "this update was received from X" because at least in groups the app sender resends all the updates and also there were ideas to allow forwarding webxdc-s with all updates to the same chat in case if the app sender becomes unavailable. In fact in can be simplified to a bool column msgs_status_updates.should_resend, from_id isn't really needed, but it can be helpful, even if for debugging. This should_resend shoud be 1 at least for initial status updates which set up the app, but also the last owner-generated status update should be re-sent and bring the integrated app state to new subscribers. This way it can scale. But this requires writing broadcast-capable apps in a special manner.