Implement the binding:profile port attribute in ML2

The binding:profile port attribute defined in the portbindings API extension will be implemented in the ML2 plugin. This attribute is a dictionary that can be used (with admin credentials) to supply information influencing the binding of the port. This functionality is needed for SR-IOV PCI passthrough, and may also be needed as other monolithic plugins that use binding:profile are reimplemented as ML2 MechanismDrivers. The binding:profile attribute will be used for input to the plugin (and its drivers) only, not for output of information originating from within the plugin. A separate portbindings extension dictionary attribute, described in https://blueprints.launchpad.net/neutron/+spec/vif-details, is available for outputting binding-specific information (to the VIF driver).

The ML2 plugin will store the binding:profile attribute in its ml2_port_bindings DB table. Values can be passed in via create and update port operations, subject to access control. Values will be returned in output dictionaries from create, update, and get port(s) operations, also subject to access control. In updates, the new value will completely replace the previous value, with no attempt to merge new and existing dictionary items.

Since the ML2 plugin can support a variety of MechanismDrivers with varying needs for content in the binding:profile attribute, the plugin will accept, store, and return arbitrary key/value pairs within the dictionary. This is unlike other plugins that only handle values for specific keys. No validation of items within binding:profile by drivers is planned, but could be added later if needed. Drivers are expected to ignore binding:profile items they do not recognize.

The current value of the binding:profile attribute will be available to all MechanismDriver port methods via PortContext.current. In update methods, the previous value will also be available via PortContext.original.

Because the contents of binding:profile can influence the outcome of ML2's port binding process (assuming MechanismDrivers that use it are configured), the semantics of updating binding:profile while the port has an existing binding need to be addressed. Initially, updates to binding:profile will be handled identically to updates to binding:host_id, triggering rebinding. If future use cases require avoiding unnecessary rebinding, the plugin could later be changed to ask the bound MechanismDriver whether the change invalidates the current binding.