feat: New dm_add_uk(), dm_rm_uk() and dm_get_all_uks() functions for explicit support of unique keys

[TSchiefer]

unique key = UK.
Can possibly also be called "weak keys".

• There can be an unlimited number of UKs (also updated doc of PK to clarify that only 1 PK can exist per table)
• adding a foreign key whose parent table doesn't have a PK, or whose PK doesn't match the fiven PK-cols results in creating a UK in the parent table
• UKs are listed in print.dm(), should they exist
• UKs are added in dm_paste() in case option keys is chosen

This PR is already based on #1715 before its merge (1st commit here) to avoid having to deal with ever changing snapshots.

closes #622

[TSchiefer]

currently still missing:

1. glimpse.dm()
2. dm_draw()

Thinking that this could be done in a follow-up PR or 2

[TSchiefer]

now dm_get_all_uks() has the following output:

suppressMessages(devtools::load_all("~/git/cynkra/dm"))

dm_for_filter() %>% 
  dm_rm_pk(tf_4, h) %>% 
  dm_get_all_uks()
#> # A tibble: 7 × 3
#>   table uk_col kind       
#>   <chr> <keys> <chr>      
#> 1 tf_1  a      PK         
#> 2 tf_2  c      PK         
#> 3 tf_3  f, f1  PK         
#> 4 tf_5  k      PK         
#> 5 tf_6  o      PK         
#> 6 tf_6  n      explicit UK
#> 7 tf_4  h      implicit UK

^{Created on 2023-01-10 by the reprex package (v2.0.1)}

[TSchiefer]

I think I now addressed everything apart from #1716 (comment)

[TSchiefer]

Wanted to mention, that currently there is no message that an explicit UK is set when adding a FK with no corresponding PK in the parent table. But I think that could be done in a later PR.

[krlmlr]

There's no longer the need to add an explicit UK when adding a new FK for new columns, these UKs remain implicit. Or were you referring to implicit UKs? We don't need to message for implicit UKs either.

[krlmlr]

Thanks. Can we do one more run, and merge when green?

[krlmlr]

I believe 93-105 can go now entirely?

[krlmlr]

I don't understand this code, but we'll notice if it causes trouble.

[TSchiefer]

ii contains the columns of the UK that is to be removed. We take the list of the current UKs and filter out ii. Well, as you say, let's see

[TSchiefer]

There's no longer the need to add an explicit UK when adding a new FK for new columns, these UKs remain implicit.

Right, I thought you did what needed to be done in that respect after your comment #1716 (comment). We can do it this way of course, then there are 2 ways of creating implicit UKs:

1. removing a PK/UK with a FK pointing to it
2. adding an FK without an existing PK/UK

Going to update the docs as well

[TSchiefer]

I addressed your latest comments, merging now.