Add account_id to data sources

[nhoening]

• add account_id field to data_source table
• data migration: insert account_id where user_id was used
• The POST sensor data endpoint stores account_id on data source (create/adapt a test for this)

[Flix6x]

@nhoening the only complication I found is that we need to review our policy for account deletion. I see 4 options:

1. Forbid deletion if the account is referencing a data source.
2. Allow deleting the account while keeping each data_source.account_id that references it.
3. Allow deleting the account while nullifying each data_source.account_id that references it.
4. Cascade to delete each data source that references the account.

Discussed in reverse order:

• 4. would not end the cascade choice, because we then face a similar choice for timed_belief.source_id. I do not prefer this option, because it destroys data lineage.
• 3. still destroys data lineage, albeit in a much lighter way. I still don't prefer this altering of existing data sources.
• 2. is the option I currently went with on the associated PR after I encountered this issue. My hunch is that it doesn't destroy data lineage, because the account's audit log might persevere (would need to check).
• 1. I believe this is the status quo option for deleting users (would want to check). My PR first used this option, for which one test failed (account deletion via CLI). Users can be inactivated, of course, unlike accounts. So maybe we'd need that for accounts, too.

I think it boils down to whether we rely on the audit log to keep a record of deleted users and accounts that are still tied to data sources, or just inactivate them (for users, removing personal information).

[nhoening]

I believe ii. is a decent choice.

We would need to do the same thing on the audit_log table, as it also uses foreign keys to point to user (2x, active and affected user) and account (affected).