StorageDataLake PathList incorrect response data type

There is a data type inconsistency between the API specs and the actual API response on the StorageDataLake ListPaths method.

The [specs](https://github.com/Azure/azure-rest-api-specs/blob/6d4e0d294d568a37b1f3421b789290934517d115/specification/storage/data-plane/Microsoft.StorageDataLake/stable/2019-10-31/DataLakeStorage.json#L102) define the data type of the `contentLength` on the returned `Path` as an `integer`. However, the actual JSON response from the API returns `contentLength` as a `string`.

I've included an example response below. Note that `contentLength` is not returned as a JSON integer.
```json
{
"paths": [
{
"contentLength": "14",
"etag": "0x8D8694078B645BB",
"group": "snip",
"lastModified": "Mon, 05 Oct 2020 15:08:09 GMT",
"name": "test.txt",
"owner": "$superuser",
"permissions": "rw-r-----"
}
]
}
```

This means that this API call is broken in the [Azure Go SDK](https://github.com/Azure/azure-sdk-for-go). I am not aware if this is also broken in any other generated clients.

My understanding is that changing a data type is treated as a "breaking change" ([as documented here](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/Breaking%20changes%20guidelines.md#property-type-has-changed)), however given that the spec is incorrect I suspect that this case would be an exception to that guidance.

Can anyone recommend a course of action here? If we are agreed that this is a bug in the spec then I am happy to submit a PR for a fix.

Start with specification/storage/data-plane/Microsoft.StorageDataLake/stable/2019-10-31/DataLakeStorage.json at the Path contentLength definition, then read the linked breaking-changes guidance. Confirm the API response and determine whether the specification should use a string; done means the spec and affected generated-client behavior are consistent.

Written by the indexing model from the issue text.