allow rapidfire foreground emails

[fche]

As per https://sourceware.org/pipermail/gcc/2024-April/243744.html

Please add an option to send fire email in the foreground (not in a daemon), and probably rapid-fire (reducing or removing the EMAIL_DELAY_IN_SECONDS).

[brobecke]

HI @fche ,

So very sorry to have dropped the ball on this one. I completely forgot about it!

The way forward as you suggested makes sense to me. To be more specific:

• We add a new option called block-while-sending-emails or send-emails-in-foreground, with default value set to False. If set to True, then instead of flushing the email queue via run_in_daemon, we call the flush directly.

• We add a new option called delay-between-emails, whose value is a float, with default value being 5.0, and zero being an allowed value. We then use this value as the delay between emails.

Both changes seem quite easy to do. However, I need to be upfront in saying that I'm not going to have time to work on this any time soon. Perhaps you might want to try it yourself? The changes themselves are very easy -- where you might get some obstacle could be the testsuite, as it is dependent to a good degree on the version of Git you have on your system (it's a bit fragile that way). It's been a while since I ran the testsuite, but each time a new version of Git comes out, there might be some changes in the output that affect the testsuite because it uses Git's output to do part of its validation checks. Practically speaking, before I even get started, it sometimes happens that I find myself updating the testsuite as a first step.

Meanwhile, the last resort option of disabling the emails from the hooks, and then implement them separately is indeed an option. I know it's not the easiest option, and also you lose the benefit of the hooks generating the emails. So not a great workaround.