However, after booting into Windows, I cannot boot into Linux again (grub screen does not appear, laptop boots into Windows directly)
This is most likely Windows 10 detecting that its UEFI NVRAM boot entry has been tampered with, and "self-healing" it with no regard to other OSs that might exist on the system. That is something Windows 10 will do, and as far as I know, there is no way around it.
The current state of the UEFI NVRAM boot entries can be viewed in the Boot-Repair output in your pastebin:
===================================== UEFI =====================================
BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.
SecureBoot disabled.
efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0000,0001,0003,9999
Boot0000* Windows Boot Manager HD(1,GPT,afab201a-94f8-11e8-851f-806e6f6e6963,0x800,0x12bfff)/File(\EFI\ubuntu\grubx64.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0001* ubuntu HD(1,GPT,afab201a-94f8-11e8-851f-806e6f6e6963,0x800,0x12bfff)/File(\EFI\ubuntu\grubx64.efi)
Boot0003* Internal Hard Disk PciRoot(0x0)/Pci(0x17,0x0)/Sata(2,32768,0)/HD(1,GPT,afab201a-94f8-11e8-851f-806e6f6e6963,0x800,0x12bfff)..BO
Boot9999* USB Drive (UEFI) PciRoot(0x0)/Pci(0x1d,0x0)/USB(16,0)..BO
Note that the Boot0000 entry is currently the first in the BootOrder, and while its human-readable name is "Windows Boot Manager", the actual boot file it executes has been changed to \EFI\ubuntu\grubx64.efi.
This is probably caused by your bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi, as this is literally what the command tells Windows to do.
Since Windows 10 will automatically change this back to its standard \EFI\Microsoft\boot\bootmgfw.efi as soon as it boots, and the Boot0000 entry is specified to be the first in the BootOrder, Windows' "self-healing" will effectively make the system boot directly into Windows as soon as you get into Windows.
What you can do is changing the boot order so that the boot entry for Ubuntu (Boot0001) will be the first instead. This is something Windows doesn't seem to be inclined to tamper with, as long as the Boot0000 entry is left unmodified. You could do this in several ways:
a.) Access the BIOS boot order settings, and move the entry that is (hopefully) labeled ubuntu as the first in the boot order.
b.) In Windows elevated command prompt, run bcdedit /enum FIRMWARE, find the boot entry with a description set to ubuntu and note its identifier: it will be a long UUID string in curly brackets. Then run bcdedit /set {fwbootmgr} DEFAULT {UUID of the ubuntu entry}. Note: it is important to use {fwbootmgr} instead of {bootmgr} here.
c.) in Linux, you could redefine the boot order with:
sudo efibootmgr --bootorder 0001,0000,0003,9999
This should place the ubuntu entry first in the boot order, then Windows Boot Manager, then the other existing entries in the same order they currently are.
But please read on...
Your pastebin also indicates Boot-Repair successfully did this:
mv /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi /boot/efi/EFI/Microsoft/Boot/bkpbootmgfw.efi
cp /boot/efi/EFI/ubuntu/grubx64.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
In other words, it moved the Windows bootmgfw.efi aside, and replaced it with a copy of UEFI GRUB. This is sometimes necessary to work around UEFI firmware bugs, but since your system previously worked, this probably wasn't necessary in your case. You'll need to undo this. In Mint, just sudo cp /boot/efi/EFI/Microsoft/Boot/bkpbootmgfw.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi should do it.
Alternatively, if you get into Windows, it will probably replace the bootmgfw.efi with Windows version immediately and without even telling you, in the name of "self-healing".
It appears your BIOS settings are lying to you: the "legacy mode" seems to be more like "either MBR or UEFI, but apparently UEFI is preferred".
Turning off legacy mode gives image authentication error
That would suggest "turning off legacy mode" will also automatically enable Secure Boot.
Since Windows bootmgfw.efi has now been replaced with a copy of grubx64.efi and it's being loaded directly by the firmware without shimx64.efi, it would be expected to fail the Secure Boot checks... and "image authentication error" would seem to be just that.
So, to make your ubuntu boot entry use the shimx64.efi for Secure Boot compliance, you would need sudo efibootmgr -b 0001 -l \\EFI\\ubuntu\\shimx64.efi. If Secure Boot is not in use, shimx64.efi will just directly run grubx64.efi in the same directory it's in, so this should not be harmful even if Secure Boot is not in effect.
Doing this on the Windows side is a bit trickier: again, use bcdedit /enum FIRMWARE, identify the UUID of the ubuntu entry, and use:
bcdedit /set {UUID of the ubuntu entry} path \EFI\ubuntu\shimx64.efi
