Add accountId column to Service table

[ArnyminerZ]

Organizational

Important

Please make sure an issue or discussion for this change exists and was acknowledged by the
core team before submitting. Uncoordinated pull requests may conflict with the project roadmap
and could be closed without merging — which would be a pity.
See CONTRIBUTING.md for details.

• An issue or discussion that proposes this change exists and was acknowledged by the core team.
  (The PR is still welcome otherwise, but could be closed at any time without much attention
  when it doesn't fit.)

✨ AI contributions – only check if applicable:

• This PR and its concept was mainly driven by a human. This does not apply when an issue
  is just referenced/copied into an AI prompt and then the result is submitted as PR.

PRs that are mainly driven by AI often have little worth, as everybody could just copy the issue
into a prompt. The worth of a good PR often comes from the main idea, architectural decisions etc.
behind it. So while all PRs are welcome, such PRs may be reviewed with less human attention and closed
at any time when they don't fit.

Purpose

Currently we use accountName as reference for the account in Service. But this is external, and as such, doesn't have any foreign key in the table.

Short description

• Add the accountId column (nullable), which references id of DbAccount table.
• Add new operations in the DAO (and deprecate existing ones)

Checklist

• The PR has a proper title, description and label.
• I have self-reviewed the PR.
• I have added documentation to complex functions and functions that can be used by other modules.
• I have added reasonable tests or consciously decided to not add tests.

[cketti]

I think it would be better to defer this change until all existing accounts are stored in the database and we have gotten rid of LegacyAccount. Otherwise, Service entries effectively become another source of truth of whether an account is a legacy account or a database account. This can quickly lead to problems if we make a mistake.

In the meantime we should be able to use something like this for reading (untested):

@Query("SELECT service.* FROM service LEFT JOIN account ON (service.accountName=account.name) WHERE account.id=:accountId AND service.type=:type")
suspend fun getByAccountIdAndType(accountId: Long, @ServiceType type: String): Service?

suspend fun getByAccountIdAndType(accountId: AccountId, @ServiceType type: String): Service? {
    return when (accountId) {
        is LegacyAccount -> getByAccountAndType(accountId.androidAccount.name, type)
        is DbAccountId -> getByAccountIdAndType(accountId.id, type)
    }
}

[rfc2822]

Yes let's discuss tomorrow how we continue. I think we should create the required tables in a coordinated effort as soon as the decoupling is finished / tested / released / stable.