Fix constance being accessed before database is ready and other fixes

[gsnider2195]

Closes #340

What's Changed

• Remove conditional logic for urlpatterns based on constance settings
• Update existing API views that were affected by the above change to return a 404 if the integration is not enabled
• Remove conditional logic for adding grafana navigation menu items
  • We can't do this at init because it needs to access the database
  • We can't modify the nav menu during runtime because core doesn't support removing nav menu entries dynamically
• Add a "grafana disabled" view in case a user clicks on a grafana nav menu item when the grafana integration is disabled
• Fix multiple bugs in the grafana views
  • Incorrect view names
  • Incorrectly using a reference to the model instead of the model itself
  • Delete all grafana API files since there we no API views provided by grafana integration
  • Fixed Nautobot v2.3 incompatibility caused by saved views not being able to determine the models' table classes
• Fix dev environment nautobot_config.py to fall back to constance if environment variable is not used
• Fix mattermost, msteams, slack and webex integration API views that were not requiring user to be logged in
• Add exception handling for cases when diffsync is not installed, since it's marked as optional

Screenshots

[glennmatthews]

I'm curious about:

Fix mattermost, msteams, slack and webex integration API views that were not requiring user to be logged in

These are the endpoints for receiving messages from the chat platform, aren't they? I wouldn't expect them to require Nautobot user authentication.

[smk4664]

I'm curious about:

Fix mattermost, msteams, slack and webex integration API views that were not requiring user to be logged in

These are the endpoints for receiving messages from the chat platform, aren't they? I wouldn't expect them to require Nautobot user authentication.

Yeah, these need to be reverted. The API for these views is for the chat platform to communicate with Nautobot. Each of these views have their own way to authenticate the system. For instance, Slack signs their requests.

[gsnider2195]

I'm curious about:

Fix mattermost, msteams, slack and webex integration API views that were not requiring user to be logged in

These are the endpoints for receiving messages from the chat platform, aren't they? I wouldn't expect them to require Nautobot user authentication.

Yeah, these need to be reverted. The API for these views is for the chat platform to communicate with Nautobot. Each of these views have their own way to authenticate the system. For instance, Slack signs their requests.

That's simple enough to do. I didn't have the context for why these were left wide open. These should probably also be changed to rest_framework views at some point instead of django views?

[glennmatthews]

I'm curious about:

Fix mattermost, msteams, slack and webex integration API views that were not requiring user to be logged in

These are the endpoints for receiving messages from the chat platform, aren't they? I wouldn't expect them to require Nautobot user authentication.

Yeah, these need to be reverted. The API for these views is for the chat platform to communicate with Nautobot. Each of these views have their own way to authenticate the system. For instance, Slack signs their requests.

That's simple enough to do. I didn't have the context for why these were left wide open. These should probably also be changed to rest_framework views at some point instead of django views?

They don't use DRF serializers AFAIK so I'm not sure why they would be changed over?

[gsnider2195]

I'm curious about:

Fix mattermost, msteams, slack and webex integration API views that were not requiring user to be logged in

These are the endpoints for receiving messages from the chat platform, aren't they? I wouldn't expect them to require Nautobot user authentication.

Yeah, these need to be reverted. The API for these views is for the chat platform to communicate with Nautobot. Each of these views have their own way to authenticate the system. For instance, Slack signs their requests.

That's simple enough to do. I didn't have the context for why these were left wide open. These should probably also be changed to rest_framework views at some point instead of django views?

They don't use DRF serializers AFAIK so I'm not sure why they would be changed over?

Just so they don't have to manually disable csrf checks. This is the first place I've seen @method_decorator(csrf_exempt, name="dispatch") on an API view.