Merge ga_login module

What is the upgrade path?

Is there recommended procedure/order of operations for removing GA Login and using what will now be in cor TFA?
It would be nice if the upgrade doesn't require users to set up up TFA all over again. Is that possible?

There is nothing to do for users using the new version. The only action would be to remove the ga_login module from composer.json but that should only be done after the database update that disables ga_login is executed.

It doesn't seem as simple as that.
I couldn't upgrade TFA to 2.0@alpha without first disabling and removing ga_login because it has a strict requirement for the earlier version:
I tried modifying composer.json to use the new 2.0 version (changed "drupal/tfa": "@alpha" to "drupal/tfa": "^2@alpha") and ran composer update drupal/tfa. The response was

 Problem 1
    - Root composer.json requires drupal/tfa ^2@alpha, found drupal/tfa[2.0.0-alpha1, 2.0.0-alpha2] but these were not loaded, likely because it conflicts with another require.
  Problem 2
    - drupal/ga_login is locked to version 1.0.0-alpha6 and an update of this package was not requested.
    - drupal/ga_login 1.0.0-alpha6 requires drupal/tfa ^1.0 -> found drupal/tfa[1.0.0-alpha1, ..., 1.0.0] but it conflicts with your root composer.json require (^2@alpha).

I actually tried that above command twice, the second time with --with-all-dependencies because the above response also included a suggestion that that would help. Apparently not.
Disabling ga_login and removing it from composer first and then upgrading TFA unsurprisingly lost my existing TFA code, so I'm prompted to set up two factor authentication again.

The removal of ga_login happened before the fork 2.0. The solution was as I outlined in #9, but first you use the latest 1.0 version, update the database, and in the second phase you can upgrade to 2.0 and remove ga_login from composer.json at the same time.

It is simply not possible to try ga_login and tfa 2.0 together, as these never existed at the same time.

Figured it out. Presenting here, because our situation is likely non-unique.
We are using Config Split → such that TFA (& GA Login) are/were only enabled in production. As a result, the config changes, particularly those handled by tfa_update_8006 and following were being countermanded by the Config Split settings, which re-enabled GA Login in production. (I wasn't getting any database updates because they had already run in the past.)

Here's how to resolve for anyone who finds themselves in the same Catch-22 situation I described above:

1. Set your dev environment to think it's whatever environment actually has TFA & GA Login enabled. (In my case that meant temporarily changing a line in my settings.php to indicate I was in "prod" and not "local.")
2. In the key_value table of the database, there's an item with the name "tfa" and a value indicating the last hook_deploy_N that's been run. Change it to 8005, so that the next database update will re-run everything with a higher number
3. Run drush updb or drush deploy
4. Login. You should still need whatever TFA code you normally do. Verify that GA Login is disabled, and that TFA settings make sense, in that you should now see the use of the core plugin(s) instead of the GA one(s).
5. Remove GA Login from the config split settings so it doesn't get re-enabled again
6. You should now be able, as @jcnventura describes, to tell composer to remove GA Login and update TFA to the 2.0 branch
7. Export your new config with drush cex
8. You should now be able to reset your dev environment to its usual settings, i.e., undo step 1
9. Before deploying code to an environment where TFA is enabled (& GA Login erroneously), you will need to re-update the database, i.e., repeat steps 2 & 3