refactor: stop using msgs.to_id

[link2xt]

Removing all uses of msgs.to_id so it can be moved to deprecated/unused section: #8493 (comment)

[hpk42]

please add some PR description/motivation. Is this intended to remove all uses of the column? Is there any issue resolved by your PR series? Or is is it anyway in draft mode and you are playing around with PR stacking?

[link2xt]

Added a link to the discussion in a PR #8493 from which this commit is split off.

Is this intended to remove all uses of the column?

Yes, this is what "stop using msgs.to_id" means.

Is there any issue resolved by your PR series?

No, it's a refactor commit.

Or is is it anyway in draft mode and you are playing around with PR stacking?

This one is not in draft mode, it's a refactoring split off the draft PR.

[hpk42]

Added a link to the discussion in a PR #8493 from which this commit is split off.

Is this intended to remove all uses of the column?

Yes, this is what "stop using msgs.to_id" means.

well, but aren't there several writes left to to_id including into the sql column in https://github.com/chatmail/core/blob/link2xt/mwsmuvztpxpl/src/chat.rs ?

Is there any issue resolved by your PR series?

No, it's a refactor commit.

CONTRIBUTING.md (which you pointed me to in prior conversations) seems to not contain such an exception. Also it recommends branch names such a <username>/<feature> and yunrlkmkmwwu etc does not read like a feature name one can easily memorize or relate to.

In any case, i don't get why this PR must be stacked with the sqldoc one on top. That was standalone before, and not far from merging IIRC.

[link2xt]

Documented to_id in #8493 instead.

It turned out to_id cannot be removed completely as it is used to mark webxdc info messages as info while keeping the from_id of the original sender to collapse messages by the same author into one.

In any case, i don't get why this PR must be stacked with the sqldoc one on top. That was standalone before, and not far from merging IIRC.

Main reason was trying to remove to_id and document it as deprecated/unused, but it turned out that to_id has this special use that is difficult to get rid of. It is essentially a strange way to mark info messages without changing from_id. Commented further at #8493 (comment)