I have several thoughts on this....
First, I recommend against installing Ubuntu 20.04 at this time. Ubuntu 22.04 is the current LTS release. Ubuntu 22.04 will be supported for longer than 20.04, and 22.04 includes more up-to-date packages. That said, I doubt if using Ubuntu 22.04 would help you fix your problem; this is more a matter of general advice.
Second, the error message you're seeing suggests that your computer's NVRAM storage may be either full or so fragmented that Shim can't create a new variable. You might be able to improve matters a bit by removing redundant or unwanted EFI boot variables. The easiest way for you to do this is probably to boot my rEFInd boot manager; there's a USB flash drive image available that should boot directly (that image does not use Shim, which also means that you'll have to disable Secure Boot to boot it). Once in rEFInd, there's a second-row option to adjust NVRAM-based boot entries. You should be able to use that to delete unwanted boot entries. Be careful, though; delete only options that you're certain are unnecessary or redundant! Ultimately, though, I suspect that the problem is Secure Boot db and dbx keys, and/or Shim MOKs. Your firmware probably has an option to reset the Secure Boot db and dbx keys to their defaults, but precisely how varies from one computer to another. I couldn't find instructions on doing this for your Dell, but I did find this article about how to do it on an HP computer. Maybe that'll be helpful, or at least point you in the right direction. It's also conceivable that your firmware includes an option to reset everything to factory defaults, which might (or might not) clear the NVRAM of all the variables it's acquired over time. Note, however, that Secure Boot db and dbx keys exist for a reason, and deleting them can cause security problems. If you can't boot your computer, though, that can be an even bigger problem, so you may have little choice but to accept an increased security risk and either make do with a slimmer dbx or disable Secure Boot entirely.
Concerning the fact that shimx64.efi doesn't exist on the live image, that's because it has a different name. Removable media (CD-Rs, USB flash drives, etc.) boot using the fallback filename of EFI\BOOT\bootx64.efi; shimx64.efi is renamed to that filename on them. On an Ubuntu installer, EFI\BOOT\bootx64.efi (Shim) then launches grubx64.efi in the same directory; so with Secure Boot disabled, you can launch GRUB directly by renaming grubx64.efi to bootx64.efi. Note, however, that if this works, the installer with put Shim on the hard disk (as EFI\ubuntu\shimx64.efi), so you'll need to create a non-Shim boot path (using efibootmgr; see here for details) or rename grubx64.efi to shimx64.efi in that directory. (The former is the better option, if it works....) A further complication is that, given the nature of your problem, the installer might not be able to create a new boot entry, so rebooting after the install might fail. This leads back to the above solution -- cleaning up the (presumably) over-full NVRAM.
Finally, as @guiverc notes, switching the computer to boot in BIOS/CSM/legacy mode is an option. Most UEFI-based PCs (those made since 2011 or so) are UEFI-based, but most of them also include a Compatibility Support Module (CSM), which enables them to boot legacy BIOS OSes. Hence, the three terms BIOS, CSM, and legacy are more-or-less interchangeable in this context. All three rely on the CSM compatibility layer of the UEFI, so the computer remains UEFI-based when booting a BIOS-mode OS; but any given OS installation will be one or the other. Thus, you can probably work around these problems by doing a BIOS-mode install of Ubuntu. The trick is forcing the computer to boot in BIOS mode rather than in EFI mode. This is most easily accomplished by removing the EFI-mode boot loaders, which are files in the EFI directory on the boot medium. Whatever tool you used to create the boot medium will have to have included a BIOS-mode boot loader, too. Note also that this approach works best if the computer is to boot ONLY BIOS-mode OSes, because GRUB 2 can't switch between boot modes. That is, the BIOS-mode GRUB 2 can launch only BIOS-mode OSes, and the EFI-mode GRUB 2 can launch only EFI-mode OSes. Thus, if you want to dual-boot an existing EFI-mode Windows alongside Ubuntu, it's best to stick with an EFI-mode Ubuntu installation, if at all possible. If you must mix boot modes, then my rEFInd boot manager can do the trick, but you'll need to enable support on the scanfor line in its refind.conf file. Using rEFInd in your case has the disadvantage that you'd still need to create an EFI boot entry for it, and that might not be possible, given the overcrowded state of your NVRAM. Also, no matter how you do it, booting in BIOS/CSM/legacy mode means giving up the protections of Secure Boot, so this approach is not preferable to deleting the dbx from a security point of view.
So in sum, there are a number of possible solutions and workarounds to your problem, but ultimately, my suspicion is that your best option is to clean up what I suspect is an overcrowded NVRAM.
