DeviceLayer and DeviceManager: Add system managed network

[kghost]

The system managed network uses the network already existing on the
system. It can be used for demonstration and daily development. It
requires no extra hardware at all, and easy to set up.

The patch includes interface to implement system managed network, it can
be implemented in the device layer of the target platform outside the
source tree. Linux device layer will have its own implementation using
the given interface.

Change-Id: Ibb488010e9fc2711bc0c00beba73d6e829a91fe5

[gerickson]

While this seems handy, can you clarify how the Weave Device Manager or a Weave mobile client would view such a device? Would it appear to have zero Thread, WiFi, or Ethernet networks?

[kghost]

There is nothing to do with Thread or WiFi network. Currently there are no Ethernet network in weave.

I can't find the interface to query whether the type of network is supported by a specific device. So I don't think it will change the behavior of how Weave Device Manager or a Weave mobile see the device.

For WDM which support system managed network, the command add-system-managed-network can be issued from user, so the device will be able to utilize the new type of network.

The feature is not supposed to be used in product, so I don't think Weave mobile client is going to support it at all.

[jaylogue]

@kghost : If I understand correctly, this change is intended to support test environments, where some form of simulated device is being used. As you stated, no real device will ever have a "system managed" network. As a consequence, the process of pairing such a device will be different from pairing a real device, and no real commissioning application (like the Home app) will be capable of performing that pairing.

This blocks a lot of possible testing using the simulator, greatly diminishing its value. It also runs the risk that developers will come to rely on these features alone for testing, possibly missing bugs in the real code path until the code is actually run on a device.

In general, it is highly desirable to have simulators act like real devices as much as possible. In the case of a simulated device that doesn't actually have a WiFi interface, the best approach is to have the simulator in some way pretend to have WiFi, allowing commissioners to go through the motion of provisioning a network, even if it has no effect.

I'll also note that we very much do not want to change the core protocols of Weave to add simulation-specific features. Such "testing-only features" have a way of becoming expected behavior, at which point people start asking for the feature to be supported on real devices. Thus, when we make changes to the core Weave protocol, we want those changes to be in support of real product use cases.