feat: allow software conflicts resolution

[jreidinger]

Problem

There is missing conflict resolution in Agama web UI.

Solution

Implement it with having it in backend, dbus, http API and also in web UI.

Testing

• Added a new unit test at front-end side
• Tested manually by @jreidinger

Screenshots

Click to show/hide a few screenshots

---

Bear in mind that these screenshots might be outdated because changes requested by reviewers after uploading them. They will be replaced only if these changes are highly noticeable

Warning with link at Software page

Software conflicts resolution page when there is only one conflict

Software conflicts resolution page when there are multiple conflicts

Software conflicts resolution page when there are no conflicts

[coveralls]

coverage: 62.701% (-0.09%) from 62.794%
when pulling ddf7970 on conflicts
into 56edc07 on master.

[dgdavid]

@jreidinger I think UI internals are now in a better shape. A few unit tests were added, as well as some aesthetic changes.

Please, feel free to review these changes and make as much suggestions as needed.

Thanks!

[dgdavid]

@jreidinger @imobachgs Sorry guys, but help needed with Rust part here.

I think I messed it up while merging master, although the needed change looked pretty straightforward to me. See f22ae09 and 3d039d9

[lslezak]

Minor issues, but probably sending the complete data in the event is not a good idea.

[lslezak]

I'm not sure if it is a good idea to send the complete list of the conflicts as a part of the event via the web socket. There might be dozens of conflicts and sending them to all clients sounds too much to me. Not all clients might be interested in the details, like the agama monitor client.

I'd prefer no details in the event and let the client to fetch the data again if it needs them. With Tanstack query it is enough to invalidate the cache, it will re-fetch automatically.

Something like:

        queryClient.invalidateQueries({ queryKey: [conflictsQuery().queryKey] })

See https://tanstack.com/query/v5/docs/framework/react/guides/query-invalidation

[dgdavid]

Make sense. I didn't know why we were doing an optimistic update here and thought that there were a reason. But if no body opposes I'll go for the invalidation as you suggest.

[dgdavid]

I guess that apart of changing the frontend for just invalidating the query some changes are needed in the backend for not broadcasting all the conflicts

[lslezak]

Agama example:

agama/web/src/queries/status.ts

Lines 82 to 88 in 9116f0e

	if (type === "IssuesChanged") {
	queryClient.invalidateQueries({ queryKey: ["status"] });
	}
	if (event.type === "ProductChanged") {
	queryClient.invalidateQueries({ queryKey: selectedProductQuery().queryKey });
	}

[imobachgs]

Good point. However, how big (in size) the list of conflicts can be? I would consider changing it only if it is a real problem. In general, I dislike those events where you need to do another fetch to get the real data, although I understand that in this case it could make sense.

However, I think that a proper solution would be to allow the subscribers to choose the "topics" they care about, so they only receive a lot of useless information. But we are not there yet.

[lslezak]

Yes, the backend needs an update as well.

[imobachgs]

I have reviewed the Rust part.

[imobachgs]

Good point. However, how big (in size) the list of conflicts can be? I would consider changing it only if it is a real problem. In general, I dislike those events where you need to do another fetch to get the real data, although I understand that in this case it could make sense.

However, I think that a proper solution would be to allow the subscribers to choose the "topics" they care about, so they only receive a lot of useless information. But we are not there yet.