[specific ci=Group23-VIC-Machine-Service] Format VCH creation log API response to text/plain

[AngieCris]

Fixes #6598

The VCH creation handler log output text/plain format (log messages upon 200 response code, and error string in all other HTTP error codes).

A snippet of how the handler response looks like upon 200:

Oct 10 2017 14:28:43.865-07:00 DEBUG Creating VMOMI session with thumbprint E6:57:47:95:CD:A4:BE:C9:10:9B:94:47:8D:57:59:07:EE:AA:F1:93
Oct 10 2017 14:28:44.300-07:00 DEBUG Session Environment Info: 
Oct 10 2017 14:28:44.300-07:00 DEBUG vSphere resource cache populating...
Oct 10 2017 14:28:44.410-07:00 DEBUG Cached dc: 
Oct 10 2017 14:28:44.577-07:00 DEBUG Cached cluster: 
Oct 10 2017 14:28:44.851-07:00 DEBUG Cached host: 
Oct 10 2017 14:28:45.028-07:00 DEBUG Cached pool: 
Oct 10 2017 14:28:45.080-07:00 DEBUG Cached folders: 
Oct 10 2017 14:28:45.080-07:00 DEBUG Error count populating vSphere cache: (1)
Oct 10 2017 14:28:45.080-07:00 DEBUG new validator Session.Populate: Failure finding ds (): default datastore resolves to multiple instances, please specify
Oct 10 2017 14:28:45.080-07:00 INFO  Validating target

Upon HTTP error codes:

"No log file available in datastore folder"

Integration tests are added to verify output containing log messages is multi-line, and error response is of string type.

[zjs]

I think this produces the right behavior (i.e., that the handler produces plain text responses), but I don't think this is the best implementation.

Currently, the swagger.json file specifies that this endpoint should produce a response of type "application/json" (as that is the value inherited, and not overridden, by the handler).

It seems like we should:

1. Specify that this handler produces responses of type "text/plain".
2. Rely on the auto-generated go-swagger code to return text. (I think redefining GetTargetTargetVchVchIDLogOK et. al is necessary only because go-swagger doesn't know we're trying to return text.)
3. Pass error messages as strings (instead of error models) to the NewGetTargetTarget*VchVchIDLogDefault methods, if necessary for go-swagger to treat them as strings. (It'd be surprising for a consumer to call an API with an Accept header that indicates it's expecting a response of "text/plain" and get a response of "application/json" instead.)

I also wonder if we can expand the existing tests in the 23-05-VCH-Logs robot test suite to verify this change.

[zjs]

I think it might make sense to define a response for this (e.g., #/responses/error-plain) to avoid duplication between the two handlers.

[AngieCris]

Thanks, just added the change

[mdharamadas1]

lgtm