Add chown option to `nfs_export_add`

[dsonck92]

• Adds an optional chown=uid:gid option to nfs_export_add. This allows a remote system to specify its desired UID/GID for the export. UID/GID are numerical as:
  1. Python accepts this by default
  2. The remote system might not have the same UID/GID mapping and this can be used together with anonuid/anongid

I think this basic implementation should suffice given the current implementation. Later, when some form of access control is in place, this chown could be limited to what the client is allowed to set. The feature is configurable and default off as it's potentially a security hole.

[dsonck92]

I've incorporated the tests as per request, I actually discovered a few bugs that way. I've also slightly reformatted some code so it's closer to PEP8 standards which seems to be followed globally in this project already.

[tasleson]

@dsonck92 @triluch @agrover Will hold off on merging this until we have some discussion on returning values for an existing API call that previously didn't return values. My thinking is that clients would only be checking to see if the request completed successfully and not check if some data was returned that they weren't expecting.

[dsonck92]

As mentioned above, the go based provisioner (iscsi-targetd) does not actively check for the return type. However, once this API is returning values:

• If a field is renamed but a client did not specify this field in a struct, this will not break
• If a field is renamed and the client did specify this field in a struct, it will likely break unless it was marked optional

[tasleson]

Thanks @dsonck92 !

One of my pet peeves is when people break API's, thus my insistence on maintaining API compatibility.

[tasleson]

As mentioned above, the go based provisioner (iscsi-targetd) does not actively check for the return type. However, once this API is returning values:

* If a field is renamed but a client did not specify this field in a struct, this will not break

* If a field is renamed and the client did specify this field in a struct, it will likely break unless it was marked optional

I think we need to be careful here as languages like go with their struct JSON serialization may fail to de-serialize when things like this change. I'm thinking that having golang bindings would be good add at some point to allow easy use, and to provide another data point for API compatibility.

Obviously we can handling the incoming data in the service and whatever form that presents, but returned value once known is most likely going to stay as is.