Update email notification engine

[WillStrohl]

Is your feature request related to a problem?

There is a lot of code around how emails are generated and sent. A lot of this code is legacy and updated over the years to saitisy many use cases surrounding how DNN expected you to connect to the email API and the various conditions and workarounds that have been necessary over the years.

Since then, the email API has been updated a lot to support a lot of the more advanced things that previously required custom code.

Describe the solution you'd like

Rewrite the email classes to use the current DNN email API directly, and remove all unnecessary legacy logic.

Describe alternatives you've considered

None yet.

Additional context

This step will likely be necessary before we do anything else with email. Such as the recent issue #163 for adding digests.

[johnhenley]

#I would push back on this since I actually spent a lot of time in the email code to get portal-specific SMTP working because the core API doesn't work correctly:). The only change I would make is to remove the option to send immediately vs using the queue and just always use the scheduler/queue.

[WillStrohl]

Maybe the description could be better written. I was attempting to write it based on what I remember from our previous conversations and updates. Though, isn't there still legacy email code that can be removed?

[johnhenley]

@WillStrohl I've studied this a bit and I thinking up a better title :)

[johnhenley]

The original implementation has some drawbacks that are rooted in very old limitations in the DNN scheduler. In particular, the scheduler could only handle small units of work. The use of the mail queue is optional, and even when used, the logic for queuing up notifications is called from the UI thread. This imposes a performance penalty on a forum with lots of email subscribers, since a poster has to wait while notifications are queued. Additionally, the email notification logic is spread across multiple classes.

The proposed changes include:

• removing the "use queue" option and always use it. This will make some code simpler
• Implement a more generic queuing controller which will become the base for any type of queued work
• implement a "new post" queue which handles any workflow actions currently handled in the UI and forces the user to wait. Examples are the reordering of previous/next pointers between topics, and updating last update timestamps, etc. Adding an single entry to "new post" queue should be all that is done vs current logic which looks up subscribers and queues each individually. 🙃
• Move any notification code out of the UI and into the "new post" queue. This includes handling moderation notifications as well as regular notifications.

@WillStrohl @Timo-Breumelhof @skamphuis do you agree with this direction? Not going to happen all at once but it's not insurmountable.

[Timo-Breumelhof]

Sounds good to me :-)