feat(worfklows): Allow server side pagination and filtering for workflows

[javirln]

This pull request introduces offset-based pagination to the control plane API, alongside other enhancements. The most important changes include the addition of new pagination request and response types, updates to the workflow service to support filtering and pagination.

Pagination Enhancements:

• Added OffsetPaginationRequest and OffsetPaginationResponse types to handle offset-based pagination.
• Updated pagination.proto to include definitions for OffsetPaginationRequest and OffsetPaginationResponse.

Workflow Service Enhancements:

• Enhanced WorkflowServiceListRequest to support additional filtering options and included OffsetPaginationRequest for pagination.
• Added OffsetPaginationResponse to WorkflowServiceListResponse to return pagination information.
• Introduced WorkflowActivityWindow enum to represent the time window for the last known workflow activity.

Possible filters:

• workflow_name
• workflow_team
• project_names
• visibility of a project
• workflow run runner type
• last known workflow run status
• last known activity of an associated workflow run

Other changes

Removes the parameter project_reference from WorkflowServiceListRequest since it was not used anywhere.

Default behavior

This changes ensures backwards compatibility by making the pagination options, optional and if not provided only returning a specific number of workflows instead. It's advised to update to most recent version of Chainloop once released to leverage the pagination feature.

Ref: #1503

[migmartri]

Great, my main concern is about compatibility support in the API and if we have removed any functionality there i.e filter by projectID

[migmartri]

out of curiosity, is this a common response type for this kind of pagination?

last_page could be calculated by total_count / page_size >= page?

[javirln]

Depending on where you search there is a different response. It seems the most common pattern is:

• page: current page
• page_size: the number of results per page
• total_count: total number of results

I've additionally added the last_page so clients don't need to that exact calculation that you're doing. Instead, another common element is to return the amount of pages. I will remove the last_page and add a total_pages.

[migmartri]

is it mandatory? why don't we have a default?

[javirln]

The message itself is not required, only if you provide it. The only default values are in the biz layer. I can add the default values here.

[javirln]

I have been searching and I couldn't find a way to specify a default value on proto3, apparently it was an option of proto2. I have found this resource https://stackoverflow.com/questions/33222551/why-are-there-no-custom-default-values-in-proto3

In any case, rest assure there are default values if the pagination is not provided a default pagination object is created:

	// Initialize the pagination options, with default values
	paginationOpts := pagination.NewDefaultOffsetPaginationOpts()

	// Override the pagination options if they are provided
	if req.GetPagination() != nil {
		paginationOpts, err = pagination.NewOffsetPaginationOpts(
			int(req.GetPagination().GetPage()),
			int(req.GetPagination().GetPageSize()),
		)
		if err != nil {
			return nil, handleUseCaseErr(err, s.log)
		}
	}

[migmartri]

this will break compatibility, are we ok with it?

EntityRef allowed us to also find by projectID?

[javirln]

Yes, we are breaking compatibility but I have search everywhere and we are not using the field anywhere, so my take is that it's safe to be removed.

Yes, EntityRef allowed us to find by projectID, instead now, you can pass repeated number of project names.

[migmartri]

[(buf.validate.field).ignore_empty = true] not necessary is it?

[migmartri]

useless validation? [(buf.validate.field).ignore_empty = true];

[javirln]

Hmm I will check this one and the next one.

[migmartri]

Thanks @javirln for getting back to my questions. LGTM!