feat: Make startup scripts idempotent

[kr3ator]

Related Issue:

New Behavior

This PR makes sure that startup scripts won't crash on subsequent runs if some of the attributes of a given object have been changed in the database since first run of the scripts.

New function has been introduced to separate the matching_params which uniquely identify given object from other non-relevant fields provided in the params dictionary.

Contrast to Current Behavior

Currently the get_or_create method tries to get the object matching all fields provided in YAML initializer.
Problem arises when after initial object creation some of the fields are changed in the database, e.g.

Fields that make a unique match on an object are set in the match_params list on a per script basis, with a default value of ["name", "slug"] if not specified.

1. Startup script creates a 'fabric' tag based on the below YAML initializer:

- name: fabric
  slug: fabric
  color: 3f51b5

2. Then inside Netbox, we change the color to gray (9e9e9e)
3. If the container is restarted, the startup_script launches again and tries to do:

Tag.objects.get_or_create(name='fabric', slug='fabric', color='3f51b5')

4. The get portion of the method fails since the color is different now.
5. The create portion of the method also fails because tag with name='fabric' & slug='fabric' already exists.

Discussion: Benefits and Drawbacks

Above section sums up the motivation and advantages of this PR. This change is backwards compatible.

Changes to the Wiki

n/a

Proposed Release Note Entry

Feature: Make subsequent startup scripts runs idempotent.

Double Check

• I have read the comments and followed the PR template.
• I have explained my PR according to the information in the comments.
• My PR targets the develop branch.

[tobiasge]

Cloud you also run isort and black to ensure a consistent code format.

isort startup_scripts/*py startup_scripts/startup_script_utils/*py
black startup_scripts/*py startup_scripts/startup_script_utils/*py

[kr3ator]

Blacked and sorted.

[kr3ator]

Hmm mypy linting fails same as in my other PR in which I fixed that in this commit.

If we accept #730 and merge to develop I can then rebase this PR.

[tobiasge]

Looks OK to me.
@cimnine Could also take a look?

[cimnine]

Based on what criteria did you decide what the match_params should contain?

[cimnine]

Thanks for the PR. That's truely an enhancement and I believe you have found an elegant solution.

[kr3ator]

Based on what criteria did you decide what the match_params should contain?

I've analyzed deeply all the models and it turned out that 90% of the cases the "name" and "slug" parameters are enough to select an object.
For some models it was a bit of trial and error as + analisys of source code of what is a unique set for a given model.