It's likely an X.org configuration problem. Can you update your question with an X.org log corresponding to the failed login ?
How to find the log file : from the home directory of the user which you tried to open an X session with, go to the .local/share/xorg directory. There you should find a few log files, take the most recent one corresponding to a failed login attempt. You can list the files in increasing modification time order with ls -lrt. Failed X logins can be detected in the file with lines starting with (EE) towards the end, and (probably) the words fatal error.
If you can't X login yet to get to get to the X.org logs, don't forget you can login on a VT such as VT3 by pressing Ctrl+Alt+F3. If your last X login attempt as that user is a fail, just take the most recent X.org log file by copying it somewhere from where you can then post it here later by any means of your choice.
EDIT :
Are you sure it's the correct log file, I mean the one that was generated during the failed X login attempt ? Because those errors don't look fatal at all. It looks like you just took the currently running X.org file...
open /dev/fb0: Permission denied is a classic in X log files, I think it's because it tried to load some framebuffer driver when guessing the configuration. I have it too. To avoid that error, you should set up an explicit X configuration instead of letting X.org guess, but that's likely unrelated to your problem.
Running the X server as root isn't usually necessary, and from my experience, the X wrapper seems to guess quite correctly by itself if root privileges are necessary, but you can keep it for now if you feel more comfortable like that. However, I would advise that you go back to the previous automatic setting (or even non-root), once everything is running well.
Of course the problem could be unrelated to the X server, but the fact that changing the driver solves the problem, and not changing the session manager (such as going to Xfce, for example) seriously points to an X.org configuration problem. Moreover, the display manager uses Wayland, not X, to show the login screen. You could try using that too btw, from the login screen, once you've selected the user, by clicking the gear icon and choosing Ubuntu on Wayland, but even if it works, it would be good to have that X configuration problem solved.
What's the Prime profile selection on your machine ? Type prime-select query to get the answer...
You can try restarting gdm to see if things improve : systemctl restart gdm.service
REEDIT :
Glad you found a workaround ! I would not really call that a solution, however...
Actually I had a problem similar to yours after upgrading. Even worse actually, since I wasn't able to log in (even a text login was impossible), and the Grub menu wasn't displaying any more (I didn't know I had to press Esc at the time), so no recovery option, but I managed to get out of this by setting the Nvidia Prime profile to intel in a chrooted root login environment. Once I was able to boot again, I noticed the nvidia drivers were in the initramfs, hence loaded early, and managed to remove them from there by purging the cryptsetup-initramfs package, which was forcing the FRAMEBUFFER initramfs option and putting the Nvidia drivers there, which should not be the case on Optimus systems anyway.
Once I had done all this, things seemed to be OK again, but I wasn't sure my initramfs-related operation was really necessary to solve my problem, and that was maybe more related to my Nvidia driver being v430 being incompatible with the new Prime on-demand profile, and I updated to v435.
However, looking at the solution you resorted to brings back my thoughts about an initramfs-related problem. Maybe if you purge that cryptsetup-initramfs package which you possibly don't need (unless you encrypt your root filesystem), that would have solved it for you too. Anyway that either is more of a workaround than a solution, since you would have to choose between using the Nvidia driver or encrypting the root fs.
