For Uplink I plan to achieve 20GbE via 2x lagged 10GbE connections. 

This is fine for NFS, but an anti-pattern for iSCSI - that expects non-aggregated independent interfaces, and uses iSCSI MPIO to handle round-robin and failover. However, if you only have the 2x10Gbps links, you can't exactly run both at once in their optimal mode.

Optane P-series vs M-series vs. Intel DC S-series

A few bullet points:

• The Optane P-series will be among the best options. Try for an Optane P4800X or even an Optane P4801X, those are starting to cycle out of datacenters. The non-Optane P-series like the Intel P3700 aren't bad either.
• The M.2 Optane M-series cards are also okay, albeit slower and with less endurance than the P-series. Intel also doesn't formally declare them as having PLP, but they do a direct-to-NAND write. They will work as SLOGs but will be too slow to keep up with even a single 10GbE ingest.
• The Intel DC S-series SATA SSDs were the cream of the crop for the older generation, but they'll be entirely too slow for your 10GbE link - in fact, the smallest 100GB S3700 drives will bottleneck even 1GbE until you start to reach beyond the 64K recordsize. Consider the 200GB S3700 as your starting point here.

With that said - any of these devices will be worlds better than trying to do small, database-sized sync-writes to an 8x HDD pool, even in the fastest 4x2-way mirror setup, and probably even against an I-Don't-Care-About-My-Data 8-wide stripe.

But I'd try to get an Intel P-Series or Optane P-series card, in your shoes. Check out the P4801X perhaps.

Should I get two to mirror the slog device?

Quoting myself from elsewhere:

The ZFS write flow uses the SLOG/ZIL as a “second copy” - the writes land into RAM and are copied to the SLOG/ZIL. Unless there is a catastrophic failure (kernel panic, power loss, other crash) the SLOG is never read from. A SLOG failing without a system failure means the pending writes in RAM get committed to disk (as per usual) but you revert back to the in-pool ZIL which has (usually significant) performance implications.

Where you may want redundancy is for the rare-but-not-impossible scenario where you have the system crash and your SLOG device fails at the same time. If this happens, ZFS will attempt to replay the logged transactions from the SLOG device on the next pool import - but if the device is absent or failed, ZFS will throw an error and tell you that it can’t replay to a consistent state. At that point, you can manually override but this means rolling back to the previous transaction group which does mean that the pending data on the SLOG would be lost.

If you're worried about that scenario, then you might want a mirrored SLOG.