Previously, a new CAPTCHA phrase was generated when the CAPTCHA image
or audio was requested "again". For that, a counter needed to be stored in the
session, and since image and audio were fetched in parallel, any of them could
initialize the new CAPTCHA phrase. The problem appeared when they both
generated a new phrase at the same time. This resulted in a race condition,
where the image and audio had different CAPTCHA phrases and some users
weren't able to pass the CAPTCHA at all. This was occuring especially in Safari,
(maybe somehow due the type dectection range "preflight" request).
Now, the phrase is initialized on the CAPTCHA page load (and reloaded via AJAX),
so we don't need to store any additional metadata, apart from the phrase itself.
[MAILPOET-6038]x
The current Captcha class has a lot of responsibilities. It renders the captcha
image, can check if a certain captcha type is a Google captcha, if a captcha is
required for a certain email. The SubscriberSubscribeController is not only in
charge of "controlling" the subscription process but also validates, whether a
captcha is correct or not. This architecture made it difficult to extend the
functionality and introduce the audio captcha feature.
Therefore this commit refactors the captcha architecture and tries to seperate
the different concerns into several classes and objects. Validation is now done
by validators.
The CaptchaPhrase now is in charge of keeping the captcha phrase consistent
between the image and the new audio, so that you can renew the captcha and both
captchas are in sync.
[MAILPOET-4514]
