client: Pass a flag into queryOperation to skip event listener setup if not required.

[markylaing]

Is it not always necessary to set up an event listener when interacting with operations via the client. For example, many client methods call queryOperation and then call Wait on the returned operation. Instead of receiving all events, filtering by operation, then filtering by the ID of the operation, and checking the status code for "success" or "failure", we can just use /1.0/operations/wait.

[tomponline]

Can this change be pushed down in to ExecInstance itself?

[markylaing]

Can this change be pushed down in to ExecInstance itself?

It's tricky because ExecInstance calls (*ProtocolLXD).queryOperation which always tries to set up an event listener. I don't think it's possible to restructure the client to only use the operations API when dealing with operations, because the events API is used for things like listening for updates on an operation (when an image is being unpacked for example). So in order to create an instance via the CLI you must have access to the events API, which may be counterintuitive.

[markylaing]

@tomponline I've changed this to roughly what we discussed on IRC (unless I've misunderstood).

I have only skipped the event listener setup for ExecInstance and ConsoleInstance as this is sufficient for the OpenFGA work. Would you like me to go through all calls to queryOperation to check if the event listener is necessary or not?

[tomponline]

looks like tests are sad

[markylaing]

@tomponline tests should pass now if you have time to re-review.

As a side note, I think a long-term solution to this problem might be to have a GET /1.0/operations/{uuid}/events endpoint which returns only events relevant to the given operation.