Use random string instead of "off" with autocomplete for invisible captcha

What does this MR do?

Attempts to use a different autocompletion strategy for invisible captcha, to reduce problems with autocomplete and chrome.

gitlab-com/gl-infra/production#4800 (closed)

The hypothesis is that using this autocomplete attribute will improve inadvertent autocompletions -- as documented in https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#browser_compatibility

As noted in this chrome bug it's not respectful of autocomplete="off". For some people (seemingly related to some update of something -- chrome, or otherwise) autocompletes the honeypot field, which results in a "white screen". This behavior exactly describes the code in InvisibleCaptchaOnSignup, and the honeypot can be seen in params in these cases as well.

NOTE 1:

We should open an issue upstream, on the invisible_captcha gem.

NOTE 2:

There's not an easy test to add that really ensures this is going to do the right thing (other than a simple view test). But look, I tried testing this locally, regression style, and I simply don't have whatever magical incantation of stored autocomplete values that causes this issue locally, but was able to reproduce it on production.

So my only guess is that this might resolve it. I'd say let's get it merged, and then we can re-enable the invisible captcha, and monitor the exceptions. I'd say this invisible captcha is of dubious value though, since it's open source and totally in the light of day, so we could consider disabling it for all times, and even potentially remove it. Is there any proof this concept really keeps a notable amount of bots out of the system? Like, more than recaptcha does? And should it be a captcha "state", instead of different captcha types? Like, I am using invisible captcha OR I am using recaptcha. I don't much need in using both at the same time, right? Also, the honeypot names should be secret -- moved to configuration instead of the initializer.

NOTE 3:

I was asked to use a random string, but don't really see value in that. If there is confusion around this long term, that's why it's a random string.

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

• I have included a changelog entry, or it's not needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team