factor `libnvmf_host_get_ids` out from scan_topology/connect/discover code path

[igaw]

I checked what we do in Linux implementation in this scenario:

__libnvme_public char *libnvmf_generate_hostid(void)
{
	int ret;
	char uuid_str[NVME_UUID_LEN_STRING];
	unsigned char uuid[NVME_UUID_LEN];

	ret = uuid_from_dmi(uuid_str);
	if (ret < 0)
		ret = uuid_from_device_tree(uuid_str);
	if (ret < 0) {
		if (libnvme_random_uuid(uuid) < 0)
			memset(uuid, 0, NVME_UUID_LEN);
		libnvme_uuid_to_string(uuid, uuid_str);
	}

	return strdup(uuid_str);
}


int libnvmf_host_get_ids(struct libnvme_global_ctx *ctx,
		      const char *hostnqn_arg, const char *hostid_arg,
		      char **hostnqn, char **hostid)
{
[...]

	if (!hid) {
		hid = libnvmf_generate_hostid();
		if (!hid)
			return -ENOMEM;

		libnvme_msg(ctx, LIBNVME_LOG_DEBUG,
			 "warning: using auto generated hostid and hostnqn\n");
	}

	/* incomplete configuration, thus derive hostnqn from hostid */
	if (!hnqn) {
		hnqn = libnvmf_generate_hostnqn_from_hostid(hid);
		if (!hnqn)
			return -ENOMEM;
	}
[...]
}

That means if all fails we just generate a UUID and use this one. I just realized I moved this part under CONFIG_FABRICS feature flag. Looks like the generate hostid/hostnqn should always be available. Let me fix this.

Anyway, I think it would be good to have something similar on Windows, so the ports behave similar.

Originally posted by @igaw in #3440 (comment)

[igaw]

In fact, we need to refactor the whole hostnqn/hostid lookup. The library should not do any lookup itself in the scan_topology/connect/discover phase, because the lookup strategy etc is policy. Instead the caller needs to settle on a hostnqn to use. This is the only sane way to handle this.