rpc: NewAPI constructs faulty HTTP client when using Unix Domain sockets

[djdv]

Checklist

• This is a bug report, not a question. Ask questions on discuss.ipfs.io.
• I have searched on the issue tracker for my bug.
• I am running the latest kubo version or have an issue updating.

Installation method

built from source

Version

No response

Config

This is the only relevant part

  "Addresses": {
    "API": [
      "/unix/C:/tmp/sock",
      "/ip4/127.0.0.1/tcp/5001",
      "/ip4/192.168.1.40/tcp/5002"
    ],

Description

Consider an IPFS daemon running on Windows, exposing its API on a UDS located at C:\tmp\sock.

The following program will fail when calling core.Pin().Ls (or anything that makes a request)

package main

import (
	"context"
	"fmt"

	"github.com/ipfs/boxo/coreiface/options"
	"github.com/ipfs/kubo/client/rpc"
	"github.com/multiformats/go-multiaddr"
)

func main() {
	const nodeMaddr = `/unix/C:/tmp/sock`
	maddr := multiaddr.StringCast(nodeMaddr)
	core, err := rpc.NewApi(maddr)
	if err != nil {
		fmt.Println(err)
		return
	}
	pins, err := core.Pin().Ls(context.Background(), options.Pin.Ls.Recursive())
	if err != nil {
		fmt.Println(err)
		return
	}
	for pin := range pins {
		fmt.Println(pin.Path())
	}
}

with this output:
parse "http://C:\\tmp\\sock/api/v0/pin/ls?stream=true&type=recursive": invalid port ":\\tmp\\sock" after host

The client constructor is using the multiaddr's Unix component's value, for the HTTP address.
This is problematic since the file system path may contain any number of invalid HTTP URL characters or sequences, which can confuse the client when it goes to make requests.
In this specific case, a : in the path is being misinterpreted as the port separator.

PR #10019