r/trigger: re-introduce query_json for deeper validation

[jharley]

In v0.2.0 we dropped query_json from r/trigger to smooth out few a gnarly bugs associated with the Plugin SDK. With that change the ability to more deeply validate that a Trigger's query met the requirements was sadly lost.

Since then, r/trigger has been re-written in the new Plugin Framework and with it we got the ability to determine if the configuration was building via Query ID or Query JSON. This change takes advantage of that ability and re-introduces deeper validation for Trigger query's so long as you use query_json in place of query_id

[cewkrupa]

Does returning early here mean it successfully validated or that it failed?

[jharley]

Neither: we can't validate anything that isn't there

Edit: which, I guess is "success" in a sense. Validators generate warnings or errors if there is an issue but otherwise allow things to continue

[cewkrupa]

Ok, maybe this is a mental model fail on my part -- I was thinking about the line above

if resp.Diagnostics.HasError() {
		return
	}

which to me read a bit like "if there's an existing error the config of the trigger resource fails validation". But maybe it means something closer to "if there's an existing error [or we don't have queryJSON]", don't run further validation"? If that's right, that makes sense 👍

[jharley]

That's a different error case: it means we were unable to get the configuration so we fail out right away.

These functions don't have returned results (no boolean or error), but instead add to a *resource.ValidateConfigResponse -- often with the intention of adding more than one error or warning -- but there are also cases where you know it's not safe to continue.