Lack of interest [Developer Tool] Allow override of mail transport inside \XF\Mail\Queue

[DragonByte Tech]

Currently, if we wish to send email instantly, we are able to override the email transport using code like so:

        if ($mailingList->email_transport['emailTransport'] != 'default')
        {
            /** @var \XF\Mail\Mailer $mailerClass */
            $mailerClass = \XF::extendClass('XF\Mail\Mailer');
            
            $transport = $mailingList->email_transport ? $mailerClass::getTransportFromOption(
                $mailingList->email_transport['emailTransport'], $mailingList->email_transport
            ) : null;
            $mail->send($transport);
        }
        else
        {
            $mail->send();
        }

However, there is no way to override the transport in the mail queue:

                if ($mailer->send($message, null, $record))
                {
                    $this->db->delete('xf_mail_queue', 'mail_queue_id = ?', $record['mail_queue_id']);
                }

...at least, not without overriding the whole public function run($maxRunTime).

For this reason, I would like to request a minor change to the above code block:

                if ($mailer->send($message, $this->getTransport($message), $record))
                {
                    $this->db->delete('xf_mail_queue', 'mail_queue_id = ?', $record['mail_queue_id']);
                }

And a new function at the bottom of the file:

    protected function getTransport(\Swift_Mime_Message $message)
    {
        return null;
    }

Use case: I would like to determine whether the transport should be overridden by inspecting the headers in the message. When queuing the email, I would set a header like X-DBTech-Mailing-List: 1 and look up whether mailing_list_id = 1 should override the transport in the \XF\Mail\Queue class.

The reason why the transport may wish to be overridden is simple; certain email services such as Google Apps do not allow you to send promotional / bulk email via their service, or have restrictive email per hour limitations to prevent bulk email.
For that reason, a website administrator would wish to use these email services for transactional email (account registration / contact us emails) to maximise deliverability, but would want to revert to the server's own mail server (or a 3rd party system) to send bulk email.


I can't foresee this change requiring much development time to implement nor test during QA, so I'm hoping this can be implemented for 2.1.3