Because:
- Attempting to format a list of integers for Slack log processing
  crashes if any of the integers can be interpreted as an IP address.

Because:
- Devices in Kind belong to different services, and should potentially be
  grouped into separate NAV installs.

Because:
- We don't need a huge traceback when the API explicitly tells us we made a
  client error (400 Bad request), as the body will include an actual error message
  we can use.

Because:
- We keep seeing random timeout errors in production.
- It's better to retry operations that time out a few times before
  giving up completely - this runs in the background sending cron mail,
  so we should try to take care of our own problemns ;-)

Because:
- simeple_rest_client raises generic "ClientConnectionErrors" on read
  timeouts. The real reason is only discoverable by checking the
  exception's __cause__.

Because:
- It's not clear whether the implicit timeout in the underlying library
  is "infinite" or some arbitrary value, but we keep getting timeouts
  in production.

Because:
- The newest version of simple_rest_client seems to have requirements
  that cannot be satisified.
- We don't know that this code is compatible with simple_rest_client
  1.0.0

Because:

- NAV 5.0 drops SNMP attributes as part of the Netbox model, introducing
  the concept of management profiles. Kindnavsync needs to be able to
  work with both pre-5.0 and post 5.0-versions of NAV for now.

Support for older NAV versions can be dropped later.

Also update to a trove license classifier that matches the actual license.

Viste seg vanskelig å debugge disse feilene mot en testserver :)

also ditch IPy in favor of ipaddress, which is built-in in Python 3