Performance improvements to mod_forum email tasks

While looking at MDL-69725 I think there is a lot of room for performance / scaling improvements to the way forum emails are sent. For each adhoc tasks there is 20 database calls made of overhead to get started and then ~11 calls per post email sent.

Lots of work is delegated to each adhoc task per user, but I think slightly too much has been pushed onto the adhoc task. The main forum cron task has already loaded a lot of data which then needs to to be re-loaded again in each adhoc task but there it is at least order of magnitude greater load on the database in total.

For example there are 4 different visibility and capability checks which are done or re-done inside the adhoc task on the off chance that permissions have changed since the email was queued. Under normal conditions there will not have changed and are redundant. Under conditions where the permissions had changed and lets say that 100 emails for users in that course were queued and 50% have been processed prior to the permission change then they'd be sent while the ones after it would not be, despite all emails being in the same boat. It is purely an arbitrary condition in the timing of task api internals which is the difference and nothing to do with the posts or users. Yes the later people will get an email with a link to a post they can't read, but that is exactly the same behavior as the ones processed before the permissions change.

Under really bad conditions, like if tasks got bogged down for a week and then resumed I can see this having more real world value. So perhaps a middle ground is if the email is being sent within some time period since the post was created then don't recheck it. Many people may not even read the email until the next day so something like 4 hours seems fine to me or even a day.