Refactor email generation properties

[ST-DDT]

The email address generation function parameters are wrongly named and are lacking in some regards.

• allowSpecialCharacters is actually forceSpecialCharacters
• A list of allowed special characters might be more useful than a boolean flag for the end user.
• ...

This issue is based on a discussion the team had when talking about:

• test(git): relax email validation in commitEntry results #1876

[xDivisionByZerox]

Can this be done without a breaking change?
Do we introduce the forceSpecialCharacters option in v8.0 while deprecating allowSpecialCharacters?

[matthewmayer]

Depends on your definition of breaking change. 😀

You could argue that removing the parameter wouldn't be breaking, the docs say it "allows" special characters, not that it guarantees special characters.

[xDivisionByZerox]

So what you saying is that this is more of a fix than a refactor? Or did I get you wrong?

[matthewmayer]

I'm saying i'm pretty sure that anyone who turned this boolean on will quickly regret it as its going to generate email addresses which will fail most validators in an unpredictable way. I'd be tempted just to deprecate it (without replacement) in v8, maybe point the deprecation message to this issue, and see if anyone complains that thiis is important for their workflow?

[ST-DDT]

Team Decision

We don't need this for v8.0.
(We will likely immediately start with v9 after v8.0)