Existing users are never matched unless creating new users is enabled

Problem

The admin is logged out of the site upon enabling the module and all users are permanently locked out, as the local authentication and login form is unavailable after enabling the module. Logging the current user out is a consequence of a separate issue that I also addressed: https://www.drupal.org/node/2859664; with that issue solved, the user will stay logged in and will have a chance to change the problematic setting of the module, but if he does not do so before he logs out (most administrators may be unaware of this problem), he runs into the aforementioned situation as well. Even after applying the workaround mentioned above, this problem still poses a considerable limitation.

Explanation:

If the REMOTE_USER is set, the _webserver_auth_route() function performs the following steps:
1. First, it attempts to log the user from the REMOTE_USER in.
2. If this fails, then if the webserver_auth_match_existing configuration variable is TRUE, it attempts to match an existing user - that means, to add a record to the authmap table for an existing user with the same login and a record only in the users table.
3. If this also fails, then if the webserver_auth_create_user configuration variable is TRUE, it attempts to create a completely new user - both a record in the users table and a record in the authmap table.

What's the root cause:
The check for the webserver_auth_create_user happens even before the step 2. As there is return; here in the case webserver_auth_create_user is FALSE - and it is FALSE by default, the code that attempts to match an existing user is never reached. Therefore existing users are actually not matched despite webserver_auth_match_existing is TRUE by default.

This definitely runs against the intended behaviour of the module, as the comment on the line 180-181 in the webserver_auth.module states: 'match_existing must be TRUE initially so admin users aren't logged out when they enable the module'.

IMPORTANT NOTE: This is certainly the problem when using Webserver authentication with the Apache module mod_auth_gssapi. However, I cannot figure out how the can work as intended for other authentication scenarios as well, as I deem this problem universal, at least for fresh installations, when there are certainly no existing user records in the authmap table - but it seems that other users don't encounter this problem. Or do they? Feedback on this is especially welcomed.

Workaround without a patch

Easier: manually insert webserver_auth_create_user set to TRUE to the system table in the database.
Sometimes desired or cleaner: manually create records in the authmap table for users.

However, this will not remove the limitation that existing users cannot be matched without creating completely new accounts for unknown users being enabled, what may cause difficulties and complications in the long term.

Proposed solution

I suggest moving the check for webserver_auth_create_user from before the attempt to match an existing user after it, right before the attempt to create a completely new user. This will effectively make these two options independent on each other. webserver_auth_match_existing set to TRUE by default will start making sense (now it means practically nothing, at least for my setup).

I have tested this solution and it worked. See file patch2.patch - note that this file is generated from GitHub repository and expects that the patch for issue https://www.drupal.org/node/2859664 has already been applied.