This PR introduces a new configurable option called userInfoProperty. When this is provided, the value set to userInfoProperty will be looked up in the properties dictionary. If the resulting value is a string, it will be parsed into a RaygunIdentifierMessage object and set on the User section of the Raygun message payload. Parsing is based on the ToString implementation of RaygunIdentifierMessage. This does not support the RaygunIdentifierMessage being destructured, though I wouldn't expect it to be needed in the log message - support for this could be added another time. Providing a RaygunIdentifierMessage in this way will negate the use of the existing userNameProperty if it's also set. The default is null so that this feature is opt-in. This helps us avoid picking a default property name that some one is already using for some other purpose.
I've also made it so that if a RaygunIdentifierMessage is provided with this new feature, then the value is removed from the properties collection. This is so that the value does not double up in the User section + the CustomUserData section. This is what I intend to solve with https://github.com/serilog/serilog-sinks-raygun/issues/23 for all other properties. However if the UserInfo property is provided, but this does not result in a valid RaygunIdentifierMessage, then the given UserInfo value will be left in the custom data dictionary.
Implements https://github.com/serilog/serilog-sinks-raygun/issues/22
This PR introduces a new configurable option called userInfoProperty. When this is provided, the value set to userInfoProperty will be looked up in the properties dictionary. If the resulting value is a string, it will be parsed into a RaygunIdentifierMessage object and set on the User section of the Raygun message payload. Parsing is based on the ToString implementation of RaygunIdentifierMessage. This does not support the RaygunIdentifierMessage being destructured, though I wouldn't expect it to be needed in the log message - support for this could be added another time. Providing a RaygunIdentifierMessage in this way will negate the use of the existing userNameProperty if it's also set. The default is null so that this feature is opt-in. This helps us avoid picking a default property name that some one is already using for some other purpose.
I've also made it so that if a RaygunIdentifierMessage is provided with this new feature, then the value is removed from the properties collection. This is so that the value does not double up in the User section + the CustomUserData section. This is what I intend to solve with https://github.com/serilog/serilog-sinks-raygun/issues/23 for all other properties. However if the UserInfo property is provided, but this does not result in a valid RaygunIdentifierMessage, then the given UserInfo value will be left in the custom data dictionary.