Fix noninteractive mode still requires user interaction

[vgdaut]

Related to issue #3848

When non-interactive mode is enabled, install and uninstall commands still prompted you if multiple refs match. In my PR, these commands fail if the argument turns out to be ambiguous.

To prevent this error, scripts should specify the repo and the exact name of needed app/runtime: flatpak install --noninteractive flathub app/org.videolan.VLC/x86_64/stable. In case there is any ambiguity, an error like this is printed:

$ flatpak install --noninteractive doom
error: Multiple refs match 'doom', unable to proceed in non-interactive mode

When multiple refs with the substring "doom" are installed:

$ flatpak uninstall --noninteractive doom
error: Multiple refs match 'doom', unable to proceed in non-interactive mode

[chrisawi]

This doesn't cover every case, for example with auto_remote when a ref is found in multiple remotes.

I think it would be more effective to add a noninteractive parameter to flatpak_resolve_*() in app/flatpak-builtins-utils.c.

[chrisawi]

Suggested change

	return flatpak_fail (error, _("Multiple refs match '%s', unable to proceed in non-interactive mode"), argv[1]);
	return flatpak_fail (error, _("Multiple refs match ‘%s’, unable to proceed in non-interactive mode"), id);

argv[1] isn't necessarily the right string.

Flatpak isn't very consistent about quoting in messages, but fancy single quotes seem to be the most common.

[chrisawi]

Looks good to me.

I didn't expect most of the flatpak_resolve_*() functions to be able to immediately short circuit, but I still think it makes sense to centralize it in the functions that show the prompts.

I could also bikeshed about the opt_ prefix on the parameter name, but I don't want you to waste time making trivial changes until a maintainer has a chance to look at it. (I have no idea why opt_search_ref is named like that, it's not even an option...)

[vgdaut]

I could also bikeshed about the opt_ prefix on the parameter name, but I don't want you to waste time making trivial changes until a maintainer has a chance to look at it. (I have no idea why opt_search_ref is named like that, it's not even an option...)

I agree. But I stick to the present style because that's not what my pr is about.

I didn't expect most of the flatpak_resolve_*() functions to be able to immediately short circuit

I also thought about requiring to specify repo when --noninteractive, as script users may have multiple repos with same refs while script author has just one repo. This can lead to author having no problems with their script but users seeing errors. But such a requirement would be too constraining.