CosmosClientOptions: Adds validation for ApplicationName

[NaluTripician]

Pull Request Template

Description

User found that when ApplicationName contains an invalid value, the SDK is basically blocked (all requests fail). In order to prevent this, validation was added when setting application name that checks to see if it contains any illegal characters or values using the HttpHeaders.NameValueHeaderValue.Parse function. If found the SDK will throw an ArgumentException letting the user know that their ApplicationName contains illegal characters. Some of the aforementioned illegal characters can be found in the RFC1783 page 2 and 3. It should also be noted that although the "&" symbol there is said to be unsafe, through testing it appears to be a valid symbol to be used so the list of illegal characters for the SDK is slightly different than the ones mentioned in RFC1738, but the Parse function is able to tell which of these value are indeed unsafe.

Type of change

Please delete options that are not relevant.

• [] Bug fix (non-breaking change which fixes an issue)
• [] New feature (non-breaking change which adds functionality)

Closing issues

To automatically close an issue: closes #3040

[github-actions]

Please follow the required format: "[Internal] Category: (Adds|Fixes|Refactors|Removes) Description"

Internal should be used for PRs that have no customer impact. This flag is used to help generate the changelog to know which PRs should be included. Examples:
Diagnostics: Adds GetElapsedClientLatency to CosmosDiagnostics
PartitionKey: Fixes null reference when using default(PartitionKey)
[v4] Client Encryption: Refactors code to external project
[Internal] Query: Adds code generator for CosmosNumbers for easy additions in the future.

[NaluTripician]

I also want to note that like @ealsur mentioned in the issue the actual validation is not being done by the SDK therefore we cannot use the HttpHeaderParser.ParseValue method to check to see if the value will 100% work. When an ApplicaitonName is added, the final parsing is on not just the ApplicaitonName but additional text added by the HttpClient. For instance, if our application name is <Run>d__9 like the user had in their issue, the actual text the parser checks is 6.0.0-rc.2.21480.5|N|<Run>d__9. Although we are not checking the entirety of what the HttpHeaderParser does, I imagine that checking for these illegal characters will provide a fix for most if not all similar problems.

[ealsur]

@NaluTripician The source of the problem is the HttpHeader failure, why did we revert that in place of the individual character validation? What is the benefit? Are there any characters that could still make the HttpHeader fail?

[NaluTripician]

@NaluTripician The source of the problem is the HttpHeader failure, why did we revert that in place of the individual character validation? What is the benefit? Are there any characters that could still make the HttpHeader fail?

The previous function I was using was using in the HttpHeader class was not working however I have found the correct one and updated the code to use that.

[FabianMeiswinkel]

Substring(20) seems artificial on initial glance - needs some explanation or changes to the code to make it easier to understand.

[FabianMeiswinkel]

LGTM

[ealsur]

Thanks! Just one small comment, please mark the PR ready for review

Bot not reacting correctly