Switch from Openflow 1.0 to 1.3

[silvia-anderson]

• Implement plugin architecure
• Turn OpenFlow 1.0 infrastructure into a plugin, and test it
• Turn OpenFlow 1.3 infrastructure into a plugin, and test it

[craig-riecke]

So I'm running into a bunch of type safety issues using IPC with Sockets/Pipes. The problem child is Reader.read_marshall which blindly tries to unmarshall an Ocaml variable, and if the types are not present or unexpected in the catching code, it just segfaults. This is bad, and caused Issue #483 as well.

In an issue I opened with Jane Street, they're response was read_marshall is just an overall bad idea janestreet/async_unix#11, and suggested using bin_prot instead. This is now looking like a good idea. The problem is the IPC protocols we've built have little or no documentation, and this would force us to document them.

[craig-riecke]

Well scratch that. Using bin_prot quickly descended into static checking hell - basically having to add [@@deriving bin_prot] into every type in Frenetic. It wasn't bad until we hit the opaque types that Frenetic punts on - in particular Packet In and Packet Out which take packet data. These are of type Cstruct.t and you can't apply bin_prot to that type because you end up creating type aliases for all the subtypes, and end up with a shadow type system for all of Cstruct. Yuck.

[craig-riecke]

Pull request #512 established plugin architecture. So now the only thing that's left is:

• Rewrite frenetic/openflow.ml to send OpenFlow 1.3 messages to switch. (by a command switch? by writing an entirely separate openflow13.ml executable?)
• Morph async/frenetic_openflow0x04_plugin to match new plugin architecture signature
• Create a mechanism to choose Openflow 1.0 or 1.3 (command line switch? discovery?)