add to C layer callbacks for download part of commit

[jreidinger]

Adds to pkg commit action download callbacks. More will follow.

I try to limit scope of this pull request to setup base for some callbacks to start with.
Real progress calls is not implemented here as from API I am not sure how it will work with software scope which is now splitted into Download and Install parts. @imobachgs feel free to add notes, todos or even code of that progress calls.

[mvidner]

Reviewing the high level part (agama-software) only for now, I think the TODOs should get implemented now

[mvidner]

NP: I feel the bottom half of the fn is boilerplate and we will want to factor it out as more callbacks appear

[jreidinger]

yes, I am sure that at least more helpers for ProblemResponse handling will be useful. So lets see how it will end.

[jreidinger]

I plan to revisit it when more callbacks appears

[jreidinger]

I add there documentation for trait and its methods where I know. But one thing confuse me as yast have DoneProvide, but it is used for both problem and also finish where response is ignored.
@lslezak how it is expected to work? I am not sure if I fully get original yast logic at
https://github.com/yast/yast-pkg-bindings/blob/853496f527543e6d51730fd7e3126ad94b13c303/src/Callbacks.cc#L572

@mvidner if my theory about how it works originally, then DoneProvide is problem method in callback, so it is already there, I just have to implement it in this PR, but lets wait for @lslezak explanantion.

[lslezak]

I add there documentation for trait and its methods where I know. But one thing confuse me as yast have DoneProvide, but it is used for both problem and also finish where response is ignored. @lslezak how it is expected to work?

Yes, this is quite messy, I was already confused by this several times. IIRC it was implemented this way to keep the compatibility with the callbacks in the YCP code (and was not changed later after transpiling to Ruby).

You do no have to 100% mimic the pkg-bindings code in Rust, some parts are really ugly and just kept to not break some old code. You can write it better. 😃

[mvidner]

I wonder why this enum has a "keep in sync" note and explicit numeric values but the others above don't have those.
How do I tell which enum needs the stricter treatment?

In any case, would it be helpful to add libzypp source URLs for reference to more places?

[jreidinger]

not sure about this...reason why to keep it in sync is that in C enum is just number and we use this feature to have problem and optional problem just problem with one additional entry appended.

[mvidner]

NP: UserData is a zypp-core concept, basically a dict<String, Any>. I would like to see the type (schema) of the particular UserData for each callback

For example this one is documented at
https://github.com/openSUSE/libzypp/blob/3e26209c0fd4e004374fd7aa6aae8d15e6ab40c7/zypp-logic/zypp/ZYppCallbacks.h#L189
but it's hard to link to 😢

[mvidner]

https://opensuse.github.io/libzypp/ exists (Doxygen rendering) but has no search function 😢

[jreidinger]

agreed. Ideally I would like to see schema against we can check during compilation time as some data has mandatory parts and also optional ones.

[mvidner]

LGTM now, thank you!