Fix incorrectTypeForFlagError for unknowns

[danhunsaker]

The reflect package doesn't always know what to call a type in (reflect.Type).Name(), but almost always gets it right in (reflect.Type).String(). Fall back to that so we get actionable error messages.

What type of PR is this?

• bug

What this PR does / why we need it:

When configs parsed into MapInputSource are looked up, they report type mismatch errors, as expected. However, if the type is mismatched for any reason, the error message isn't particularly useful - it reports an "actual type" of ''. This is a known limitation of the way (reflect.Type).Name() works (it only provides names for package-defined types, not built-in composites or pointers or a handful of other things). Falling back to (reflect.Type).String() in these cases provides enough data for a developer to fix the actual issue (in this case, using the correct type in their InputSourceContext implementation), which is the entire point of returning a type name in that specific error message.

v3 doesn't have support for InputSourceContexts (or any equivalent I could find), so this fix currently only targets v2.

Testing

A test was added to ensure this change works as expected.

Release Notes

NONE

[skelouse]

Why don't we just do:

fmt.Errorf("Mismatched type for flag '%s'. Expected '%s' but actual is '%T'", name, expectedTypeName, value)

func TestXxx(t *testing.T) {
	var value *string

	func(_value interface{}) {
		fmt.Printf("Got: %T", _value)
	}(value)
}

// Output: Got: *string

[danhunsaker]

That's a good idea. Wonder if %T existed when this was originally written...

[skelouse]

That's a good idea. Wonder if %T existed when this was originally written...

Looks like it has been around since go1, https://pkg.go.dev/fmt@go1

[meatballhat]

Thank you!