CP-49953: Remove parse_uri, switch to using Uri module instead'

[last-genius]

Removed unused function, replaced the only other usage of parse_uri with the
functions from the Uri module.

Suggested here.

The original ticket also mentioned authorization_of_string as another
candidate to switch to Uri, but it parses headers, not Uris, so this
was not undertaken.

This change passed the BST/BVT test suites, and was also tested
manually by interacting with the host from XenCenter.

[Vincent-lau]

Is this uri the same as the one on L368? If so, why converting it back?

[lindig]

I would trust Uri to create standard-conforming URLs. One caveat though and why this needs testing:

utop # let t = Uri.of_string "https://foo.bar" in Uri.path t;;
- : string = ""

This might be surprising and you could have expected "/".

[last-genius]

Is this uri the same as the one on L368? If so, why converting it back?

L368's uri is the full path+query.
Here it's split into only the path, L381 further gets only the query part.

Couldn't come up with a more precise name so I just shadowed the other (as it was done before)

for example:

utop # let t = Uri.of_string "https://foo.bar/dir1/dir2?k1=v1" in Uri.path t;;
- : string = "/dir1/dir2"-
utop # let t = Uri.of_string "https://foo.bar/dir1/dir2?k1=v1" in Uri.query t;;
- : (string * string list) list = [("k1", ["v1"])]

[last-genius]

Created a separate ticket (CP-50079) for removing parse_keyvalpairs, as there are more questions and complexities there (to discuss at the next standup, should also discuss if more tests are needed here already, or in the new ticket).

Restored the exception handling over Uri's interface - could someone review this please? (it's one line - L377 in http_svr.ml)