Add support to expose the Issues API

[imobachgs]

Trello: https://trello.com/c/7SUGZlbi/349-expose-the-issues-interface-over-http

• It enables the org.opensuse.Agama1.Issue interface over D-Bus.
• It fixes a problem when handling status changes (WithStatus).

[coveralls]

coverage: 74.412% (-0.09%) from 74.498%
when pulling 3e6ae2a on http-issues-api
into 80ac668 on better-errors.

[jreidinger]

to be honest I am not sure if I expect subtree under issue or other way /software/issues. Probably later makes more sense to me. Or having general /issues call. Would it be possible?

[jreidinger]

similar here. I would either expect some id in issue report that can be used to make it specific or at least use just product-issues, otherwise naming looks inconsistent

[imobachgs]

I am not using those IDs for anything, so they aren't relevant. I decided to, somehow, match the D-Bus structure (/org/opensuse/Agama/Software1 and /org/opensuse/Agama/Software1/Product).

However, if we use it as an ID, we could get rid of the service, hiding to the client the fact that it is talking to a D-Bus service:

WithIssues("software/issues")

instead of

WithIssues("software/issues", "/org/opensuse/Agama/Software1"

In that case, I would adjust the events-related types to something like:

pub type Scope = String;
pub type EventsSender = Sender<(Scope, Event)>;
pub type EventsReceiver = Receiver<(Scope, Event)>;

Does it make sense?

[imobachgs]

On the other hand, keeping the scope out of the event introduces some small inconsistencies, like being able to send a LocaleChanged event from any unrelated scope. But I guess I can live with that.

I have been also thinking about using something like:

pub enum Event {
  Locale(LocaleEvent),
  Software(SoftwareEvent),
};

And then each service defines its event types:

pub enum LocaleEvent {
  LocaleChanged { locale: String },
  IssuesChanged(IssuesChangedEvent),
  ProgressChanged(ProgressChangedEvent)
}

In this case, the scope is implicit.

I would like to think a little bit about that (and other options we could think of). For now, I will just update the IDs to make them look better and more consistent.

[jreidinger]

makes sense to me to think a bit about it and what is more important document decision, so we will be consistent.

[imobachgs]

Just a note about the second proposal: if you can emit a IssuesChange in several places from a single service, you still need a way to differentiate them.

[jreidinger]

👍