Extendable URI parser

[IvanRibakov]

Current URI parsing logic is optimized for performance AND for dealing with SIP/SIPS URI schemes. Unfortunately, this is a limiting factor for SIP services who's business logic needs to deal with other types of URIs: http/https, tel, urn, cid, etc.

Of course, separate implementation-side parsers may be created by sipgo users and SIP message parts that contain URIs (generally speaking those are various headers) can be re-parsed based on individual needs. However, such approach comes at a cost of a more complicated implementation-side code. For example, consider Geolocation header. According to spec it can hold a multitude of different scheme URIs:

• sip/sips
• pres
• http/https
• cid
• etc

It is common for all Geolocation header values to be processed together by some location-based piece of logic. For developer it would be extremely convenient to be able to:

1. have Geolocation parsed using some generic address-type header parser similar to From/To header parser (headers that contain one or more address values + parameters)
2. retrieve all Geolocation header values from a SIP message
3. pass the collection of header values to another function for processing

If we assume a custom implementation-side parsing logic (for Geolocation header and URIs contained as values), then it may not seem so different/complicated at first. But once we add other complicating factors like the need to access same header values in several different places in the code then we either need to start caching the custom parsing results or face the penalty of re-parsing non-core headers/values each time we need to access them.

Proposal

1. Make URI logic extendable by allowing to register custom parsers for different URI schemes (similarly to how header parsing can be extended) a. By default ship sipgo with parsers for sip/sips scheme as is the case now
2. Add "unparsed" state to the current URI struct to allow capturing original URI string value without the risk of making bad parsing decisions by the generic/default parser
3. Define a convention for representing other URI types and converting to/from generic Uri type
4. Add missing URI fields to the current URI struct. As far as I am aware, only path is missing at the moment (consider http:example.com/foo/bar URI)

Caused by https://github.com/emiago/sipgo/pull/114 (@emiago thank you for your support on it!)