chore: Add ShowByID filtering generation

[sfc-gh-fbudzynski]

Changes

• ExtendedIn name changed from "In" to "ExtendedIn"
• Added ShowByID filtering options to implement_functions template
• New filed in Operation struct with Filtering options

To generate filtering options, add filtering options in ShowByIDOperation:

).ShowByIdOperation(
	g.ShowByIDLikeFiltering,
	g.ShowByIDExtendedInFiltering,
)

Test Plan

• acceptance tests for secrets
• integration tests for secrets
• unit tests for secrets

• Used secrets as base for testing how filtering generation works

[github-actions]

Integration tests failure for 1599afb36a36122395af19213ab1a4562b220e90

[sfc-gh-jmichalak]

I'm open for discussions, but I'm not sure if it's necessary. On the other hand, in Snowflake, is just IN, and initially ExtendedIn was used only to distinguish from In with limited filtering capabilities.

[sfc-gh-fbudzynski]

It will change how the filtering in the template is handled and how we should define filtering for the ShowBiIDFiltering struct. But it can be changed if it is preferred to leave the Extended In as before.

[sfc-gh-jcieslak]

For me, it's more readable that way because I know it's the extended version, but both options are ok.

[sfc-gh-jmichalak]

We can leave the default behavior as it is, but we can point the SDK users to use g.ShowByIDLikeFiltering, and others more explicitly.

[sfc-gh-fbudzynski]

How about: // TODO: adjust request if e.g. LIKE is supported for the resource with ShowByIDLikeFiltering and other filters for "ShowByIdOperation" in the definition file."

[sfc-gh-jmichalak]

Sounds good.

[sfc-gh-jmichalak]

We can use it (non-extended In) in one object to show if it works.

[sfc-gh-fbudzynski]

good idea, i will generate some objects to show all the filtering options

[sfc-gh-jmichalak]

I wonder if we could use an enum instead? What if we have more showByIDs which have a different behavior? Such flag could be confusing.

[sfc-gh-fbudzynski]

You're right, that would probably be a better approach than just a flag

[sfc-gh-jmichalak]

In your doc you proposed sth like

	ShowByIDSchemaFiltering     ShowByIDFilteringKind = "In{Schema: id.SchemaId()}"
	ShowByIDInDatabaseFiltering ShowByIDFilteringKind = "In{Database: id.DatabaseId()}"

I'm not saying it's bad, but I'm curious about the other approach here.

I wonder if we can separate these abstractions (one is database vs schema, and the other is in vs extended in)

[sfc-gh-fbudzynski]

I don't think we can skip the In vs. ExtendedIn because those filterings use different structs. For ExtendedIn, we need to provide the ExtendedIn struct, and for Simple In, just the In struct.

I aimed to make it similar in use to what we have for the ShowOperation:

g.NewQueryStruct("ShowSecret").
	...
	OptionalLike().
	OptionalExtendedIn(),

and then for the filtering we use:

).ShowByIdOperation(
	g.ShowByIDLikeFiltering,
	g.ShowByIDExtendedInFiltering,
)