allow to define certain destination capabilities via configuration

[rudolfix]

Background
Some of the destination capabilities may be changed by the user, for example:

• default decimal, integer, text or timestamp precision
• naming convention

ideally we would allow user to change certain via capabilities of Destination and via configuration ie

[destination.postgres.capabilities]
decimal_precision="9,3"
naming_convention="duck_case"

Requirements

1. • allow the capabilities to be set via property of Destination
2. • create base capabilities that can be a part of configuration with settings for which configuration make sense
3. • write tests
4. • document both methods in Destination docs

[rudolfix]

@steinitzu I could see you had to subclass the destination to change default decimals. why? it seems it is in the properties? so you can create postgres() instance and then change it?

[steinitzu]

Hey @rudolfix , yeah you could monkey-patch the property on client class and replace the factory method.

This on both job client and sql client classes is the annoying part:

class PostgresClient(InsertValuesJobClient):
    capabilities: ClassVar[DestinationCapabilitiesContext] = capabilities()

We should pass them to __init__ from factory.

[steinitzu]

We could just remove the capabilities property and make it a field on DestinationClientConfiguration, no?
Should be pretty minimal change and makes it editable along with other options.

[rudolfix]

yeah that would work but:

capabilities: ClassVar[DestinationCapabilitiesContext] = capabilities()

could not be a classvar anymore but should be instantiated per instance. otherwise we'll get the initial values and those will never be modified.
I do not see we use it as classvar anywhere now. we may get rid of it finally.

Also I'd just provide a few values to be configurable in DestinationClientConfiguration not everything. some of them are callables and other should never be changed
same for sql_client.

[steinitzu]

Yeah I don't see why it needs to be a classvar either. Could be instance attr on client.

Totally makes sense not to have everything configurable, the escape functions, max_query_length, etc are all fixed.
Question if the changable params should be entirely separate then.
I.e. decimal_precision, etc should not be in capabilities at all but just be regular config fields with defaults, and we keep caps as a constant.

[rudolfix]

maybe config param are base configspec from which current capabilities derive? the problem I see is that capabilities derive from context already and context is exclusively injected by context config provider so it won't be taken from toml etc. but 100% that can be solved :)