Backend Infra to Start Analyses

[gbdubs]

Creates the core endpoints for starting a run, looking up analysis runs and analysis artifacts. The centerpiece of this PR is the RunAnalysis endpoint.

Along the way, the PR makes a few misc cleanups:

• Simplifies the interface of deleteBlobs
• Fixes how we were doing enums in oapi so that the generated code generates shared definitions, simplifying and strengthening conversion.
• Looks up the IDs of the artifacts associated with an analysis in the DB, using the query pattern of Front-end for Initiative Portfolio Participation #91 to avoid incorrect group-by patterns.

[bcspragu]

Same here, this seems like lots of nested subqueries that we don't need. What's wrong with something like:

Suggested change

	return fmt.Sprintf(`
	WITH selected_analysis_ids AS (
	SELECT id FROM analysis %[1]s
	)
	SELECT
	analysis.id,
	analysis.analysis_type,
	analysis.owner_id,
	analysis.pacta_version_id,
	analysis.portfolio_snapshot_id,
	analysis.name,
	analysis.description,
	analysis.created_at,
	analysis.ran_at,
	analysis.completed_at,
	analysis.failure_code,
	analysis.failure_message,
	aas.analysis_artifact_ids
	FROM
	analysis
	LEFT JOIN (
	SELECT
	analysis_id,
	ARRAY_AGG(analysis_artifact.id) AS analysis_artifact_ids
	FROM analysis_artifact
	WHERE analysis_id IN (SELECT id FROM selected_analysis_ids)
	GROUP BY analysis_id
	) aas ON aas.analysis_id = analysis.id
	%[1]s;
	`, where)
	return fmt.Sprintf(`
	SELECT
	analysis.id,
	analysis.analysis_type,
	analysis.owner_id,
	analysis.pacta_version_id,
	analysis.portfolio_snapshot_id,
	analysis.name,
	analysis.description,
	analysis.created_at,
	analysis.ran_at,
	analysis.completed_at,
	analysis.failure_code,
	analysis.failure_message,
	ARRAY_AGG(analysis_artifact.id)
	FROM analysis
	LEFT JOIN analysis_artifact
	ON analysis_artifact.analysis_id = analysis.id
	%[1]s ;; This is the WHERE clause I think. Also, I'd put the `WHERE ` here, so that all the callers don't have to remember it
	GROUP by analysis.id;
	`, where)

[gbdubs]

This is mostly for consistency with the other query structure. The other query looked JUST like you're proposing. But then, when I added a second nested relationship table to the query, it broke. The advantage I see of structuring it this way is to prime it so that additional joins will follow the same structure, and be less likely to fall into the pitfall I spent a few hours having to debug.

[gbdubs]

Copying this here for the discussion: #91 (comment)

[gbdubs]

@bcspragu I'll wait on your response to the two questions above before merging - I want your opinion/perspective!