URL Encoding (MQTT)

The rules for URL encoding data that is sent on the wire over MQTT are somewhat inconsistent due to the requirements of the IoTHub service. The following are the policies that Hub follows:

• MQTT Username is expected to be structured as {hostname}/{clientid}/?{properties}
• MQTT Topic for telemetry is structured as devices/{clientid}/messages/events/?{properties}
• {clientid} may stand for {deviceid} or {deviceid}/modules/{moduleid}.
• {deviceid} and {moduleid} are not encoded/decoded whatsoever on the Hub. Neither in topic, nor in username.
• {hostname} is also not encoded/decoded by Hub
• {properties} is a sequence of {key}={value}&… . Both {key} and {value} are assumed to be %-encoded and Hub WILL decode any character properly encoded with percent encoding.
• The SAS Token used as the MQTT Password is expected to have it's uri ({hostname}/devices/{deviceid} or {hostname}/devices/{deviceid}/modules/{moduleid}) URL encoded. Additionally, the URI must be encoded prior to being used to create the signature - and then the resulting signature must ALSO be encoded

Currently, other than the above specified requirements, the Python device client will encode all values as a client-side best practice, even though not relevant (e.g. a legitimate request id cannot contain values that would require URL encoding, but we encode anyway). This doesn't break Hub, because URL encoding shouldn't be changing these values, and it allows us to be consistent across the board once Hub updates their API to start decoding the MQTT topic values