itman

Version 17 is projected to be released in November;

No. Only users enrolled in Eset Beta Tester program are allowed access to Beta versions.
You will have to wait until it's released to the pre-release channel.

You've asked this question no less than 14 times in this thread.
You're fortunate that the Eset forum is tolerate of such activity. You would have been banned long ago on most security forums.

I will also add that as I have posted in other forum replies, it is virtually impossible to block nVidia telemetry via a firewall;
https://www.ghacks.net/2016/11/07/nvidia-telemetry-tracking/
As deleting this .dll can cause other issues, the only effective way to block the telemetry is via IP address blocking.

My own opinion here is Eset should commission SE Labs to perform ransomware testing as CloudStrike did: https://selabs.uk/reports/enterprise-advanced-security-ransomware-crowdstrike-2022-oct/ .

In the same Eset GUI section, you can exclude SSL/TLS scanning based on the certificate associated with the domain/URL of your web based app.

It appears "the message is not getting across here."
It also appears no one has bothered to read the posted link Microsoft article which states;
No one is forcing anyone to upgrade their Win OS version. That said, it is imperative to apply the appropriate KB update depending on Win version. If you don't, you will find Microsoft Defender real-time protection running side-by-side with Eset's.

It appears "the message is not getting across here."
It also appears no one has bothered to read the posted link Microsoft article which states;
No one is forcing anyone to upgrade their Win OS version. That said, it is imperative to apply the appropriate KB update depending on Win version. If you don't, you will find Microsoft Defender real-time protection running side-by-side with Eset's.

It appears "the message is not getting across here."
It also appears no one has bothered to read the posted link Microsoft article which states;
No one is forcing anyone to upgrade their Win OS version. That said, it is imperative to apply the appropriate KB update depending on Win version. If you don't, you will find Microsoft Defender real-time protection running side-by-side with Eset's.

If you start to monitor IP addresses out of context to their source process, you could suffer a malware paranoid breakdown.
Microsoft maintains IPv4/IPv6 backbone networks all over the world. This is the network traffic you are observing. As far as attempting to block all Windows telemetry network traffic, it is an effort in futility.

As far as what wmiprvse.exe child processes to monitor for;
https://redcanary.com/threat-detection-report/techniques/windows-management-instrumentation/
Also, the article gives multiple examples of why WMIC execution should be blocked.

Also, I believe WMIC invokes the main WMI process, wmiprvse.exe, to run the target process. So in reality, it is wmiprvse.exe that is creating the child process. I have a HIPS rule to monitor for that activity.
As far as stopping WMI via PowerShell use, the best mitigation is to set Powershell to Constrained Language mode which prevents all direct use of PowerShell subassembies via .Net invocation. Also, use of Windows Defender Application Control (WDAC) auto sets Powershell to Constrained Language mode.
-Correction- PowerShell Constained Language mode won't stop this;
Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList notepad.exe
but monitoring child process startup from wmiprvse.exe will;
Time;Application;Operation;Target;Action;Rule;Additional information
8/23/2023 3:04:21 PM;C:\Windows\System32\wbem\WmiPrvSE.exe;Start new application;C:\WINDOWS\system32\notepad.exe;Blocked;Deny child processes started from WmiPrvSE.exe;

You need to monitor WMIC startup; not child process creation. The HIPS alert Commandline will show if attempted child process creation is occurring;

Ditto for powershell startup.
WMIC HIPS rule is;

Note that MITRE's recommendation is to block WMIC execution;
https://attack.mitre.org/techniques/T1047/

Blueskying, what would be utterly fantastic is Eset ptogramming the HIPS to use MITRE detections as to LOL Windows binary abuse. Then one could specify in a HIPS rule to apply those detections against an abused process such as WMIC.

Similar posting here: https://www.reddit.com/r/Malware/comments/14nwzgh/rambler_ru_malware_hacking_accounts/?rdt=42159 .
I would think it is common sense to stay away from Russian web sites these days.
https://www.ipqualityscore.com/domain-reputation/rambler.ru

Multiple network connections show on my ver. 16.2.11 installation per the the below screen shot;

Also, care needs to be taken when removing network connections. For example, my second network connection is only used at system startup time with Eset auto switching to the first network connection shortly thereafter.
Finally, ver. 16.2.11 changed how network connections are displayed and modified. The only way to view existing network connections is via the above Network connections option. They are no longer viewable via Network access protection section in Advanced Setup mode.
Further, settings for any network connection setup automatically by Eset are no longer modifiable other than for Connection profile type; why Eset did so is beyond me. It is possible to set up a new network connection manually but you have to create a new Network connection profile to do so.

Per Eset Internet Security system requirements;
https://help.eset.com/eis/16.0/en-US/sysreq.html
Also note;

Refer to this: https://support.eset.com/en/kb6681-comparison-of-eset-liveguard-advanced-eset-threat-intelligence-and-eset-livegrid .
The main difference between LiveGuard and LiveGuard Advanced is it is designed to interface with Eset server products.
The only analysis done by LiveGrid in the Eset cloud is a file blacklist lookup. LiveGrid's primary purpose to forward suspicious files to Eset Lab for further analysis.
Feature-wise the only difference between LiveGuard and LiveGuard Advanced is LiveGuard Advanced malware detection confidence level is configurable in regards to suspicious processes allowing the user to make the decision to allow or deny execution. 

I repeated the speed test again this time using fast.com which is what you used for testing.
With Eset SSL/TLS scanning enabled, my download speed was 140 Mbps. With Eset SSL/TLS scanning disabled, my download speed was 130 Mbps! Based on these results, I would say something is wrong with fast.com speed measurement calculations.
Run your speed testing using this web site: https://www.speedtest.net/

I just ran my own ad hoc test on how long it takes for Eset to create a signature for a Cobalt Strike beacon.
I found a Cobalt Strike sample that was uploaded to the malware sharing web site on 8/11. Verified on VT that Eset was not detecting the sample with a last analyzed time of 9 hours ago. I also noted that the sample had been previously uploaded to VT on 8/3.
Downloaded the sample and upon archive extraction, Eset real-time detected it;
So sometime in the last 9 hours, Eset created a signature for this Cobalt Strike beacon. Confirmed when I reanalyzed it at VT.
From this test, one can expect a Cobalt Strike signature detection at around 10 days after submission to VT.😱

Another notable ver. 16.2 firewall change you should be aware of. If you are using Eset default firewall settings, you can ignore the rest of this posting.
Prior to ver 16.2, individual Win services could be disabled in the firewall as noted below. This option no longer exists in the ver. 16.2.

Assuming one was using the Eset Private (trusted) profile, one could disable known vulnerable and abused services such as file and printer sharing, UPnP, and remote desktop, etc.. This resulted in the applicable default firewall rules for these disabled services being auto changed to rules employed when the Public profile is in effect.
As it currently stands in ver. 16.2, your only alternative is to disable Eset applicable default firewall rules for the service and create new ones to block inbound network traffic.

Another important point to note in ver. 16.2 in regards to firewall profiles is you're not just adding a new profile per se; but in reality, a new network connection;

This is a radical departure from ver. 16.1 firewall profile processing in that a profile was tied to an existing Eset network connection;
https://help.eset.com/eis/16.1/en-US/idh_config_epfw_profiles_group.html

Prior to performing a full OS reinstall to fix the WSC issues, you might try the suggestions given here: https://www.makeuseof.com/windows-security-center-wont-start-fix/ .

The alert shown is originating from Eset's Web Access protection. It is an IP address blacklist detection as confirmed by VirusTotal detection;

If you only receive the Eset alert when you manually access some web site, do not continue to access this web site.
Otherwise, my best guess at this point is you have a malicious extension installed in Chrome and it is trying to connect to this IP address. The extension must be removed to stop this Eset alert.
Your PC is protected since Eset blocked access to the malicious remote connection.
-EDIT-
If this Eset alert appears w/o any browser open, have you recently installed a free or cracked game download? A number of these contain malware in the installer which will download additional malware from a compromised Google cloud store server. Open Eset "Filtered websites" log and search for entries related to this 104.155.138.21 blocked IP address. Open one of those entries and it will show what application was the source of the IP address traffic.