Implement trusted contacts

[juligasa]

• Create a local and private list of “Trusted Contacts” - Account IDs who you know and trust
  • Local DB migration required to add “isTrusted” column to the accounts table
• All other contacts (Account IDs) are considered “Untrusted”
• Contacts list shows a list of trusted contacts at the top, under “Trusted Contacts” heading
  • untrusted shows up in the bottom of the list, under “Other Contacts” heading
  • ListAccounts should include an isTrusted boolean for each account
• allows you to trust a untrusted contact, or untrust a trusted contact, either with a button or as a dropdown item.
• When adding a contact explicitly (pasting connection details), they are trusted by default. In the list of all the contacts, there will also be a way to trust/untrust existing contacts.
• New API SetAccountTrust with {accountId: string, isTrusted: boolean}
• Account Profile screen shows if this account is trusted. There is a button to trust or untrust this account.
  • GetAccount should return an isTrusted boolean
• Split “All Publications” into two views:
  • “Publications” - only see documents and versions that are from trusted contacts
    • When you click on one of these publications, you go to the latest version created by a trusted contact
      • the “new version” banner should only reflect the latest version made by a trusted contact
  • “Global Publications” - see all documents including from untrusted contacts
    • When you click on a publication here, you go to the latest version created by anybody
  • ListPublications can accept a new boolean flag such as includeGlobalPublications: true
  • GetPublication accepts a new boolean flag that filters the latest version from a trusted contact

Definitions
Heads: A Change with no dependants.

Steps

get all the heads, filter out those heads that are from untrusted peers, and use that as a trusted version.

So even if a trusted head depends on a change from non-trusted peer - it's OK.

And that's where the trick is, which will be a bit hard to implement. The problem is similar for filtering out drafts (this bug: https://www.notion.so/mintter/When-I-edit-a-publication-it-becomes-a-draft-and-disappears-from-the-All-Documents-5997095f6e264b01830b0d78ae9bb6f0).
You'll get all the heads, then remove non-trusted head, but this non-trusted head may depend on changes that are trusted for you, and these may now also become heads for you in this filtered view.
But you'll be ignoring them if this is implemented naively.
E.g. to find heads now I do roughly select id from changes where id not in (select parent from change_deps). So all_changes - set_of_changes_that_have_children.
And this was what was giving troubles with drafts in the bug I linked.
So I had to change this. But it was easy for drafts, because now I just do non_draft_changes - set_of_changes_that_have_children and this will give the non draft heads.
But it's not that easy for filtering out non-trusted heads.

So it's almost like it would be easier to implement the other variant of the solution.

To summarize:

Given A(Julio) <- B(Eric) <- C(Julio) <- D(Eric) if I don't trust Eric there's 2 possible outcomes:

A is my latest trusted version.
C is my latest trusted version.

Implementing option 2 seems harder than option 1 now (I thought the opposite before).

To implement option 1:

select trusted_changes = (A, C)
non_heads = select distinct parent from change_deps where child in trusted_changes
heads = trusted_changes - non_heads.

To implement option 2:

heads = queue(D)
for head = heads.dequeue() and head is not null:
  if head is not trusted:
    heads.enqueue(head.deps)
  else:
    break

Well now it seems like option 2 is still easier. At least easier to reason about. But it's harder to implement with pure SQL. But It's OK, maybe we should just implement it in code.
So, grab the heads, then for each head check if it's a draft, or if it's from non-trusted account. In this case, use their deps as heads, and repeat the process, until all heads in our set are trusted.
Implement option 2

[juligasa]

They passed the tests ,but I did a it differently that you @burdiyan said yesterday. Please see the comments below

[burdiyan]

@ericvicenti looks like there're some conflicts with Electron-related files. Could you take a look?

[burdiyan]

Left my final thoughts suggesting some changes to make before merging.