Parsing connection string is expensive

[bgrainger]

It was reported in #237 that "MySqlConnectionStringBuilder was spending around 10% of CPU time in Regex".

I profiled a program that constructed a connection string 200,000 times and got the following profiling output:

I also ran BenchmarkDotNet to compare Connector/NET ("Old") vs MySqlConnector ("New"). We are already twice as fast, but there may still be room for improvement:

BenchmarkDotNet=v0.10.3.0, OS=Microsoft Windows NT 6.2.9200.0
Processor=Intel(R) Xeon(R) CPU E5-1650 v3 3.50GHz, ProcessorCount=12
Frequency=3410075 Hz, Resolution=293.2487 ns, Timer=TSC
  [Host]     : Clr 4.0.30319.42000, 64bit RyuJIT-v4.6.1637.0
  DefaultJob : Clr 4.0.30319.42000, 64bit RyuJIT-v4.6.1637.0

 Method |       Mean |    StdDev |  Gen 0 | Allocated |
------- |----------- |---------- |------- |---------- |
    Old | 35.6826 us | 0.6354 us | 0.4720 |  11.36 kB |
    New | 18.5218 us | 0.1743 us | 0.2482 |   5.86 kB |


dotnet cli version=1.0.1
  [Host]     : .NET Core 4.6.25009.03, 64bit RyuJIT
  DefaultJob : .NET Core 4.6.25009.03, 64bit RyuJIT

 Method |       Mean |    StdDev |  Gen 0 | Allocated |
------- |----------- |---------- |------- |---------- |
    Old | 37.7715 us | 0.7290 us | 0.3825 |  10.59 kB |
    New | 20.5420 us | 0.2696 us | 0.1587 |   5.11 kB |

[MrSmoke]

Here is the MySqlConnection..ctor performance report (VS2017, running in Release) from my project (.NET 4.6.1 WebAPI2)

For the time being I've forked the project and added a simple FIFO queue to cache the ConnectionSettings object as you were correct in #237 with cloning providing no performance increase:

-------------------------------- |----------- |---------- |
                   NewConnection | 33.5918 us | 0.1941 us |
        NewConnectionWithBuilder | 27.3938 us | 0.1768 us |
 NewConnectionWithBuilderNoClone |  3.1812 us | 0.0682 us |

[bgrainger]

Since this is probably a common performance problem for all ADO.NET providers, it's most likely best addressed in dotnet/runtime.