Modify file_bucket_file API to use "application/octet-stream" instead of "text/plain" for Content-Type

The Puppet file_bucket_file API – https://docs.puppetlabs.com/guides/rest_api.html#file-bucket – requires a PUT request for a file to include a Content-Type of "text/plain". Puppet agent and file_bucket_file requests through the puppet filebucket CLI face also do not include a charset along with the Content-Type. Per various industry specifications – see https://tools.ietf.org/html/rfc6657 in particular – the default charset that a receiver should assume for this case would be either US-ASCII or ISO-8859-1. Puppet agent and filebucket CLI face requests, however, currently format the request body as raw "binary data". This is incompatible with the US-ASCII and ISO-8859-1 formats.

In order to make the client's intentions about the request body encoding more clear, it would be better for clients to include a Content-Type of "application/octet-stream".

josh suggested that we could create a new format called ":binary", map that to "application/octet-stream", and change file_bucket/file to use it. Here are some relevant locations in the code where this could be done:

https://github.com/puppetlabs/puppet/blob/master/lib/puppet/network/formats.rb#L65

https://github.com/puppetlabs/puppet/blob/master/lib/puppet/file_bucket/file.rb#L16-L27

Depending upon how we would do this, it may need to be done on a major version boundary. If the master were upgraded to accept "application/octet-stream" while still treating "text/plain" as "binary" initially, backward compatibility would be preserved. At some point, though, it may make sense to just break compatibility for "text/plain" on file_bucket/file altogether as the current implementation is ambiguous and not in alignment with industry standards.

QA:

Risk Assessment: Low? Issue didn't reproduce after all.