The names bootx64.efi and bootia32.efi refer to the EFI fallback boot loader program. This program can be anything -- GRUB, the Windows boot loader, an EFI shell, malware, etc. Thus, you should not search for a program by that name; rather, you should search for a program by its actual name (GRUB in your question) and rename it to EFI\BOOT\bootx64.efi or EFI\BOOT\bootia32.efi (depending on platform) on your boot medium. In fact, if you're installing to a computer's internal hard disk, you probably shouldn't use that name at all -- instead, you should rely on the EFI's own built-in boot manager to remember the name of the binary you want to launch. (An exception would be if your firmware is badly broken, as some still are.) The boot{arch}.efi filenames were originally intended exclusively for use on bootable removable disks, such as for OS installers and emergency recovery tools; but they're also used for boot loaders of last resort on internal hard disks -- say, for when the NVRAM entries have been damaged.
As to the main part of your question, GRUB binaries tend to be built by and for individual distributions; AFAIK, there is no official source for "the" GRUB binary for EFI. The usual way to obtain a GRUB binary is to install a Linux distribution that uses it. It will normally be installed as /boot/efi/EFI/{distname}/grubx64.efi, where {distname} is a code used by the distribution, such as ubuntu for Ubuntu or fedora for Fedora. Note, however, that simply moving and renaming this binary might not work, since it may have hard-coded paths to its configuration file. If the target computer uses Secure Boot, too, you'll need to rename the shimx64.efi or shim.efi file as the fallback filename and copy grubx64.efi, using that name, to the same directory as Shim. If you're installing to one computer, you shouldn't need to bother with moving or renaming GRUB; just install normally and it should take over the boot process -- at least, until you install the next distribution or something reconfigures the boot order.
For a system with multiple Linux distributions, GRUB can be a bit cumbersome. This is because GRUB relies on a complex configuration file to create its menu of boot options, and that configuration file is maintained within the distribution that installed GRUB. This works OK when you install just one Linux distribution, but with several distributions, you must update GRUB in the distribution from which it came in order to present new kernels installed from your other distributions. The alternative is to chainload one GRUB from another, which may work better, but is more cumbersome at boot time.
Another approach is to use a boot manager that involves less complex configuration. My own rEFInd can do this; it detects Linux kernels on each boot, so once it's set up, it can boot the latest kernel without changes to its own configuration. Other boot loaders, like SYSLINUX and ELILO, require GRUB-style configuration in a centralized configuration file, but that file is simpler and therefore easier to maintain by hand. If you use any of these tools on a removable disk, you'll need to copy it to the boot{arch}.efi filename.
There are numerous other caveats and quirks to all of this, but without knowing more about your intended use and hardware, I can't go into them all here without writing a small book. You might want to check out one or more of the following sites for more information:
I'm building a boot disk and used the SuperGrubDisk project download to get the binaries. – David Balažic – 2019-05-19T14:41:03.530