For using OpenWrt, the ipq806x target isn't quite capable to route at 1 GBit/s linespeed - it should do more than 100 MBit/s (depending on your expectations for latencies probably between 350-400 MBit/s up to ~600-650 MBit/s, with software flow-offloading enabled), but 1 GBit/s is a bit above its abilities (you would need mvebu or x86_64 for that, perhaps ipq8074 in the future). Especially with 1+ GBit/s fibre connections, you're quickly leaving the prosumer space and are fairly far into enterprise territory and converging towards x86_64.
Given that the two 1.7 GHz KRAIT300 derived ARMv7 cores can't keep up with routing at 1 GBit/s linespeed, the vendor has added two 800 MHz little-endian ubicom32 derived NSS/ NPU cores for offloading most of the networking (NAT, routing, PPP, even higher level protocols like IPsec) into hardware (well, a firmware blob running on these NSS/ NPU cores). With the help of this semi-closed NSS subsystem (free, but non-mainline, driver with a closed/ proprietary firmware running on the NSS cores), the various OEM firmwares can go beyond the performance limits of the ARMv7 SOC and actually achieve routing at 1 GBit/s line speed (at least for the protocols supported by the NSS firmware). OpenWrt currently does not take leverage of these (this would be an opportunity for a hardware flow-offloading driver, but writing this won't be for the faint of heart), leaving them dormant and using the ARMv7 cores exclusively, which means you won't achieve the same throughput as the OEM firmware for your device.
yes, at least for kernel 4.14.x (which is the current default in master or the openwrt-19.07 branch, while openwrt-18.06 was still on kernel 4.9.x), it's not available in earlier kernels and currently broken in newer ones (for all targets).
currently not available for any target but mt7621, so not for your device.
yes
Yes, this and setting the lower clockspeed boundary to 800 MHz (instead of 384 MHz) will help.
Yes.
That said, in a very synthetic local benchmark (iperf3), doing routing and NAT between two local servers (one on WAN, one on LAN) with 1 GBit/s ethernet and DHCP, my nbg6817 (using kernel 4.19.x and only irqbalance && setting the lower clockspeed boundary to 800 MHz && the up_threshold of the ondemand scheduler to 20) doesn't fare that badly either:
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 111 MBytes 928 Mbits/sec 0 551 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 936 Mbits/sec 0 578 KBytes
[ 5] 2.00-3.00 sec 102 MBytes 854 Mbits/sec 2 731 KBytes
[ 5] 3.00-4.00 sec 110 MBytes 923 Mbits/sec 0 761 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 0 761 KBytes
[ 5] 5.00-6.00 sec 110 MBytes 923 Mbits/sec 0 854 KBytes
[ 5] 6.00-7.00 sec 101 MBytes 849 Mbits/sec 0 880 KBytes
[ 5] 7.00-8.00 sec 109 MBytes 912 Mbits/sec 0 885 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 887 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 887 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec 2 sender
[ 5] 0.00-10.00 sec 1.06 GBytes 910 Mbits/sec receiver
But that's just that, a synthetic benchmark which doesn't take real world complications (PPPoE?, latencies, SQM, etc.) into account, so I really don't want to spread this as gospel. If you do want a conservative estimate for ipq8065's practical WAN-to-LAN throughput under OpenWrt, it will be somewhere between 350-400 MBit/s. Chances for NSS/ NPU support[0] for OpenWrt in the future are non-zero, but very low.
--
[0] Don't consider NSS/ NPU support to be a magic bullet, while it does provide a significant speedup, it can only offload protocols supported by the proprietary NSS firmware - and to the extent of its abilities. Bugs inside the NSS firmware would be 'unfixable', things like SQM simply aren't supported (meaning it would fall back to mere software routing again in the best case, or break spectacularly if the NSS firmware doesn't let go voluntarily).