Review the use case for scheduled traces and housekeeping

[Vinicius Arcanjo]

Historically, a lot of things have changes since scheduled traces were introduced, we should also review the use case and what we need to really maintain. Code is liability, let's keep and maintain with quality only what's really needed.

Questions to be answered:

• Do re really need TRIGGER_SCHEDULE_TRACES? this used to try to discover circuits and send slack notifications. This has been disabled on settings by default and it has 80% of duplicated responsibility based on what mef_eline already does with its consistency check, and mef_eline does it better since it also integrates it with redeploys.

• Do re really need TRIGGER_IMPORTANT_CIRCUITS? this used to rely on sdntrace and then also notifications, will this be ever be used in production?

Also, notifications are being sent to amlight/kytos_courier.slack_send that we currently also don't actively maintain, event will be discarded, no impact, we need to reassess this, confirm requirement and most likely nuke this notification part in the meantime.

@gretelliz I'll this to you since in the epic_sdntrace_cp housekeeping is also part of it, feel free to add more stuff here if needed when the time comes to address this issue in the future