fix for #2667: put email-update-confirmation code into separate controller

[azine]

Untagled some configuration dependencies between
email_confirmation (upon registration) and
confirm_email_update (when the users changes her email) to fix #2667

[azine]

I moved the confirmEmailUpdateAction into a separate/new controller, re-grouped the configuration related to the email-update-confirmation-feature, fixed a typo and added a test for the routing.

DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!!
I didn't yet run this code in a fully installed application. I only just started updating my own application from Symfony 2.7 to 2.8 (and then later 3.x). I'll give this code a try once I have updated my app.
DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!! DISCLAIMER!!!

I you (@covex-nn or @XWB or @stof or anyone else) want to give it a try before that, you are very welcome to do so and give feedback.

Cheers,
Dominik

[azine]

fixed typo: fos_user.profile.controller vs. fos_user.profiler.controller

[covex-nn]

@azine without enabling profile.email_update_confirmation feature, /profile and /profile/edit work as before. And /profile/confirm-email-update/qwerty is not accessable with this error message:

Controller not found: service "fos_user.confirm.email.update.controller" does not exist.

After enabling email update confirmation with only profile.email_update_confirmation.enabled: true, and after updating email in /profile/edit there was a error in FOS\UserBundle\Mailer\Mailer::sendUpdateEmailConfirmation

Notice: Undefined index: template

This error occurred because, there is no template key in $this->parameters. But, there is email_updating.template key, and $this->parameters['email_updating.template'] === '@FOSUser/Profile/email_update_confirmation.txt.twig'

[azine]

@covex-nn: Thanks for your feedback & testing.
The first part (service not found, when the feature is not enabled) sounds fine to me. If the feature is not enabled, the Controller is not available. The loading of the routes does not take the configuration into account (afaik).

The second part is a bug in the Mailer/Mailer.php. I fixed that and updated the PR.

[covex-nn]

@azine i checked: second part was fixed =)

After updating email, fos_user.email_canonical was changed to new value, fos_user.email had old value.
Then after visiting $confirmationUrl, fos_user.email was updated to new value too, fos_user.confirmation_token was updated back to null.

So, it works!

[azine]

@covex-nn Thanks again for testing. Leaving the canonical value of the email with the new value while waiting for confirmation, was not intentional. => I fixed this unintended behaviour.

[covex-nn]

@azine I thought, that it was a feature. I wrote about it just because is was strange =)

With last commit, fos_user.email and fos_user.email_canonical are changed only after visiting $confirmationUrl. So, it works2! Hooray! =)

[azine]

@covex-nn cool! Thanks for the "testing service". :-)

IMO thiis PR would be ready to squash & merge. @XWB or @stof : any objecttions? Anything I need to change?

[XWB]

Thank you guys.