Disable UriSyntaxFlags.UnEscapeDotsAndSlashes for .NET < 4.5

[inikulshin]

Despite the fact that .NET 4.0 is considered coprolite, I used to reproduce the issue (unescaped dots and slashes in Uri -> unable to use default vhost / in all queries) on my local machine.

Should we check and fix the issue, e.g. like @mikehadlow suggested?
http://mikehadlow.blogspot.co.uk/2011/08/how-to-stop-systemuri-un-escaping.html

Or at least throw different exception, explaining the issue?

P.S. maybe my case is related to https://devblogs.microsoft.com/dotnet/net-framework-november-13-2019-update-for-net-framework-4-8/:

The observable issue was the System.AppDomainSetup.TargetFrameworkName was null, leading to any quirks enabling reverting back to .NET Framework 4.0 behaviors.

[inikulshin]

@Pliner @zidad @micdenny @luigiberrettini FYI

[inikulshin]

I think, this one is critical.

Now we finally switched to EasyNetQ.ManagementClient.3.0.0-alpha6 (from 0.51.3... we maintained internally for years) and we get a lot of failures related to the absence of this patch. Some in mixed code, but also in pure managed.

I looked at the old sources, and this patch existed in EasyNetQ.ManagementClient many years ago, but was lost someday. We must return it back.

Update:
The code was lost here:

8bbf914#diff-1902a0dc6e27026d434957620dfca2df1ef224d12f3c9341240af6f3174c732b

• Removing LeaveDotsAndSlashesEscaped because it does not apply

[inikulshin]

Fixed in #314

[inikulshin]

Well, it's not over.

Currently EasyNetQ.Management.Client can't work with runtime TargetFramework=.NETFramework,Version=v4.0. The patch I added doesn't work for 4.0 and it looks like the patch that can fix all URIs at once can't be created.

There was a code inside ManagementClient.CreateRequestForPath that patched every single URI after creation:

4a28e76#diff-1902a0dc6e27026d434957620dfca2df1ef224d12f3c9341240af6f3174c732b

But we can't revert it now: final URI is created inside SendAsync from Endpoint and relative URI.