Enable local login in Geo secondary instance
Description
With current effort for Disaster Recovery, one thing that we can improve is to make possible to login into a secondary Geo instance, without being redirected to the primary.
There are many situations where it's easier and better to go to the primary, so this must be done either only during DR or when no other external dependency is required (like when user is using only GitLab internal login).
Background context:
The reason why we initially disabled local sign-in, is because we didn't had a database we could write to, in order to provide state, audit log and protection against many different attacks.
We know have the Tracking Database, which can be used for that. We need to evaluate the impact of this change, as we would have distributed information among all the instances, instead of everything in a single one (like audit logs will not be in the same database anymore, prevention of multiple logins attempt will not be as effective/restrictive it is now, because the limits would be multiplied by the geo nodes, etc).
Also if user has LDAP authentication, they will need to replicate that as well, if they enabled OAuth, they will need to whitelist the other vhosts etc.
This adds additional complexity to be considered as a daily driver, but can be valuable in a few situations where the users have a really bad connection to the primary location.
Proposal
1 - We make this optional on the Geo node configuration, so you can have a Geo location that can use local login, and another that uses current process (that redirects to primary).
2 - We make this possible only during DR (which would require a flag and a reconfigure). This will enable temporarily, without login any attempt anywhere (so we don't need to recreate tables on the tracking database, and because of the security implications, we would allow it only for the administrator, as this is a special situation).
On either situations, we need to make the current bypass based on the existence of the configuration flag (either per gitlab.yaml or per GeoNode configuration).
We may also need to patch Devise to do what we need it to do (write on the tracking database, or perhaps on local redis in the case of DR, just to provide something against brute force etc)
cc @stanhu @nick.thomas @to1ne @dbalexandre @jramsay @jarv