Motivation: We've found out experimentally that the whirlwind is bad at being an endpoint while simultaneously being a router.
(It seems to be bad at being a router as well, compared to a commodity netgear, but that's a story for another day). The solution here is to have a separate endpoint to talk netperf to the DUT, that is connected to the whirlwind (or equivalent router) via ethernet. 

I attempted this and have some crummy code and observations:
(a) netperf_session and netperf_runner are reasonably well abstracted out. They require a wifi_client but not a site_linux_router as the second endpoint. The second endpoint can be a site_linux_system, which is nice. 

These files do make assumption that the second endpoint talks over wifi_ip (target_ip = self._server_proxy.wifi_ip) - and I had to make ugly hacks to work around that. 

(b) Due to (a), one can now write a network_WiFi_PerfPlus.py that
inherits from test.test instead of wifi_cell_test_base. 
Why? Because we don't want to start hostapd anywhere and dont want to setup or connect to a router. We assume that a router exists, the second endpoint is already connected to it via ethernet, and the first endpoint is either already connected via wifi or can be connected (via iw or similar). 

Here is my attempt at that: https://paste.googleplex.com/6390914326986752?raw

(c) The problem: The second endpoint now has two ethernet interfaces, one for autotest control, and one for talking netperf traffic via the router to the DUT. I had a hard time setting up the routing tables to achieve (c). 

If we can fix (c), a 3-way static setup might be the best long-term for Bluetest testing.