Rewrite m_joinpartspam; improve method and flexibility

[genius3000]

• Changed mode to +x as it appears unused so far, solves conflicts with m_blockhighlight
• Block the user from joining for a duration instead of setting a ban
• Channel redirect no longer relies on another module (banredirect)
• Block duration and channel redirect are per-channel instead of network configured
• Config option of 'allowredirect', which defaults to no.
• Config option of 'freeredirect', to skip the halfop+ check for the redirect channel. Defaults to no.

I've only quickly tested this to function correctly (parses settings, blocks joins, redirects). @KoraggKnightWolf I'd highly appreciate some testing of this if you're willing.

[KoraggKnightWolf]

Dear genius3000,

Once more thank you very much for your time and efforts. Testing has been positive and there are just two things that I would like to additionally suggest, if they seem sensible and can be applied:

1. Can the message when one is effected by the mode also give out for how long the block duration is? This might be useful for incase someone is just suffering from a bad connection and wishes to rejoin and those who actively spam do not usually tend to take note of such messages anyway.

2. Can it be done that anyone can redirect to any channel without the need of being a channel operator in the specified redirect channel? One usage of this module would also be to redirect everyone who
   has a bad connection to one dedicated channel but I am not sure if this idea of a "free redirect" can be implemented so easily (or at all) into InspIRCd and wanted to know whether that could be done or
   not.

Testing has been positive, the features operate as intended.

I hope that others might be able to benefit from this module and the recent changes applied to it as well.

Regards,

Koragg

[genius3000]

1. Yeah, to keep it simple I'll add it to the initial block but not the subsequent messages.
2. How free do you want to go here? I can skip the privileges check and/or the channel exists check. Keeping the channel exists check would help catch a typo at least.

[KoraggKnightWolf]

Dear genius3000,

Once more thank you for taking the time and effort to go through my ideas. The first one as you suggested is good, being informed once should suffice (and a real spammer would not care anyway). Regarding the second one in the sense of free I meant that the person executing the redirect does not have to be a channel (half)op on the redirect channel. Could this be implemented? I would think the most common usage when one wishes to redirect is e.g. to a dedicated channel for people with connectivity issues (or perhaps a channel for actual spammers even if desired). Could it be implemented that way, that any user can redirect to an existing channel regardless of their status/access in the target channel?

Thank you once again for your time and effort in advance.

Regards,

Koragg

[genius3000]

@KoraggKnightWolf Thanks for the feedback! I've updated this with:

1. Length of block in the initial block message
2. A second config option of freeredirect to skip the half(op) check
3. Improved the error messages regarding the redirect channel

[KoraggKnightWolf]

Dear genius3000,

Once again thank you very much for taking the time and effort into optimizing the module even further and I am glad to hear that my feedback is of value.

As intended, the first block messages states for how long the person must stay out for and the redirect with freeredirect enabled does indeed skip the (half)op check as intended. I was going to mention whether just enabling freeredirects altogether was a good idea as then anyone could make them also join channels the "spammers" do not belong in but making it a config option allows each network to toggle this however it suits their needs.

Testing has been positive and the new features have been confirmed to work as intended. Hopefully other networks can find a great usage for this module too.

Regards,

Koragg