PB-1405: Split bod_migrate command

[benschs]

Model changes

Add field slug to providers and attributions. This field is non-null and unique. This allows it to be used in the url path to identify resources. It is not null and unique, which is why db migration is done in 3 steps to populate the column with default values.

Command changes

Add flags to management command bod_migrate to control which data should be migrated.
Added flags are --providers, --attributions, --datasets. They can also be combined to migrate them at the same time. Beware that --clear will still clear all the migrated data.

Currently there are 4 providers that can't be migrated:

name_de	attribution	reason
ASTRA, BPUK	ch.astra	Two entries with attribution ch.astra
SED / ETH Zürich	sss	Attribution does not contain .
swisstopo + ENSI	NULL	No Attribution
swisstopo + Erlebnis Geologie	NULL	No Attribution

Currently cannot migrate the following attribution as there is no provider ch.kanton.

name_de	attribution	reason
AV + Kantone	ch.kanton.av	Missing provider ch.kantone

The following datasets could not be migrated:

id_dataset	reason
ch.kantone.cadastralwebmap-farbe	Missing provider ch.kantone
ch.bafu.gefahren-historische_erdbeben	Provider is sss
ch.swisstopo.geologie-dosisleistung-terrestrisch	Missing provider for swisstopo + ENSI
ch.swisstopo.images-spotimage	Missing foreign key to attribution/provider
ch.swisstopo.geologie-bodenunruhe	Provider is sss
ch.astra.baulinien-nationalstrassen_aenderung_v2_0.oereb	Missing provider ASTRA, BPUK
ch.astra.baulinien-nationalstrassen_v2_0.oereb	Missing provider ASTRA, BPUK
ch.astra.projektierungszonen-nationalstrassen_v2_0.oereb	Missing provider ASTRA, BPUK

Actions

• Model changes documented in the business entity model
• Resolve issues with data that could not be migrated (TODOs in code)

[msom]

Nice! Looks good in general, some thoughts:

• Would be nice to have some tests for this new functionality (bod_migrate with only some of the flags and maybe edge cases)
• Should we use the slugs in the API instead of the ID's now that we have them?
• Should we rename bod_migrate to bod_sync?

[benschs]

Nice! Looks good in general, some thoughts:

* Would be nice to have some tests for this new functionality (bod_migrate with only some of the flags and maybe edge cases)

* Should we use the slugs in the API instead of the ID's now that we have them?

* Should we rename `bod_migrate` to `bod_sync`?

Thanks for the input. I added more test cases. I also think the name bod_sync is better and renamed it.
I also think we should use the slug in the API, but would do this in a separate PR.

[benschs]

As mentioned in https://jira.swisstopo.ch/browse/PB-1405, BOD database has been cleaned, now all providers, attributions and datasets can be synced as expected.