Fix two regressions in my 2e8b670 ("Add support for SSH certificate
authentication", 2018-06-14) merged in gitlab-org/gitlab-shell!207.

This fixes the issue noted in gitlab-org/gitlab-shell#145 where the
command-line contains things other than the key/user/username, and
also a regression where SSH certificates are being used, and the
username presented in the key is unknown to GitLab.

In that case, we should log the user in as "Anonymous" (on an instance
that allows public access), but because of how the error checking
around api.discover() was implemented we ended up erroring out
instead.

This along with the code submitted to gitlab-ce in the
gitlab-org/gitlab-ce! MR implements SSH certificate
authentication. See the docs added to gitlab-ce for why and how to
enable this. This, along with that MR, closes
gitlab-org/gitlab-ce#3457

Implementation notes:

 - Because it's easy to do, and because an earlier nascent version of
   this would pass user-ID to gitlab-shell, that's now supported, even
   though the SSH certificate authentication uses username-USERNAME.

 - The astute reader will notice that not all the API calls in
   gitlab-ce's lib/api/internal.rb support a "username" argument, some
   only support "user_id".

   There's a few reasons for this:

     a) For this to be efficient, I am bending over backwards to avoid
        extra API calls when using SSH certificates.

        Therefore the /allowed API call will now return a "user id" to
        us if we're allowed to proceed further. This is then fed to
        existing APIs that would only be called after a successful
        call to /allowed.

     b) Not all of the git-shell codepaths go through
        /internal/allowed, or ever deal with a repository, e.g. the
        argument-less "Welcome to GitLab", and
        /internal/2fa_recovery_codes. These need to use
        /internal/discover to figure out details about the user, so
        support looking that up by username.

     c) Once we have the "user id", the GL_ID gets passed down to
        e.g. user-authored hooks. I don't want to have those all break
        by having to handle a third GL_ID mode of "username" in
        addition to the current "key id" and "user id".

This reverts commit a18c90128e4d3eeae1233b1bc3c3998afd223c0d, reversing
changes made to 0a64624152735766c428d1532e434dd0bf5a9748.

By default, RubyGems is enabled, which causes the Ruby interpreter
to load 600+ additional files at startup when gitlab-shell is
designed not to use any external gems.

Hoping this makes it more obvious when code touches the very
unsafe contents of this variable.