feat: add custom error type for unsupported column types

[dgiagio]

What this PR does / why we need it:
This PR introduces a custom error type in the package sqlutil to improve error handling when encountering unsupported SQL column types. This change provides better diagnostics and enables clearer error handling for consumers of the package.

Previously, when an SQL column had a type that couldn't be processed, the code would return a generic error message via fmt.Errorf. This made it difficult for consumers to programmatically handle this specific error case.

By introducing a structured error type, consumers can now:

• Use type assertions or the errors.As function to detect this specific error condition
• Extract the exact type and column information directly from the error

Which issue(s) this PR fixes:
https://github.com/grafana/plugins-private/issues/3032

[CLAassistant]

All committers have signed the CLA.

[njvrzm]

Lookgs good to me, and I'll approve as is since it's a reasonable change, but I have a question about an alternate approach.

[njvrzm]

I noticed that some database drivers - myqsl and pq, for example - use some variant of reflect.TypeOf(new(any)) for unknown column types, where others use nil like this. Currently we handle the "any" type ones in NewDefaultConverter by converting them to nullable strings (or nil if the conversion fails).

Wouldn't it make sense here to handle both these cases the same way? Whether unknown types are represented by nil or "any" seems to be a quirk of the driver.

[dgiagio]

Hi Nathan,

Thanks for the comment. If I'm understanding correctly, your suggestion is to expand the scanTypeValue check to handle both nil and any. This would account for the different ways database drivers signal an inability to parse a column, returning either nil or an any type.

I agree that this is a a sensible approach for broader compatibility. However, the primary goal of this PR is to improve error handling specifically for the nil case, which addresses an immediate issue within the current implementation.

While a broader fix is a good idea, adding the any check might have unforeseen consequences that I haven't fully explored. I think it's best to keep this PR focused and consider the any handling in a future update.

Thanks for bringing this up!

[njvrzm]

Ah, I guess I didn't actually make a suggestion, but what I meant to suggest was to go the other way: instead of considering a nil scanType an error, handle it the same way we handle any, and process the values into strings if we can.

[njvrzm]

But! This is a larger change, so please do feel free to merge as is and we can come back to this later.