[Feature]: Rethink ListOptions for a more intuitive and natural interaction

[machine424]

Description

Despite what one may think when encountering ListOptions, it's not that immutable input that would only be used to pass options. It's also used, for example, to track the pagination state:

linodego/pagination.go

Lines 94 to 99 in 3bcb4a6

	// listHelper abstracts fetching and pagination for GET endpoints that
	// do not require any Ids (top level endpoints).
	// When opts (or opts.Page) is nil, all pages will be fetched and
	// returned in a single (endpoint-specific)PagedResponse
	// opts.results and opts.pages will be updated from the API response
	func (c *Client) listHelper(ctx context.Context, pager PagedResponse, opts *ListOptions, ids ...any) error {

The fact that it's passed by reference should warn users about its mutability, but I don't think it's sufficient. Perhaps renaming the struct or splitting it may help better.

Motivation: In Prometheus, before prometheus/prometheus#14141, we were using the same ListOptions instance over and over (which led to inaccurate results of course), I’m concerned that we might fall into the same pattern of “misuse” in the future.

Example Code

No response

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[ykim-akamai]

@machine424 , We created a ticket in backlog for this issue. We will update you once there is some progress. Thank you for your contribution!

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days