Splink 4 dialect agnostic blocking rules

[RobinL]

In this PR, I have tried to mirror the work on ComparisonLevelCreator, but for blocking rules.

Hence the user passes BlockingRuleCreator objects into the settings dictionary. These are only turned into actual BlockingRules via blocking_rule_to_obj once the dialect is known via the DB API.

Example script

import splink.comparison_library as cl
from splink.blocking_rule_library import And, CustomRule, block_on
from splink.database_api import DuckDBAPI
from splink.datasets import splink_datasets
from splink.linker import Linker

df = splink_datasets.fake_1000
df.head()

db_api = DuckDBAPI()


settings = {
    "link_type": "dedupe_only",
    "comparisons": [
        cl.ExactMatch("first_name"),
        cl.ExactMatch("surname"),
        cl.ExactMatch("dob"),
        cl.ExactMatch("city"),
    ],
    "blocking_rules_to_generate_predictions": [
        block_on("first_name", "surname"),
        And(
            CustomRule("l.dob = r.dob"),
            CustomRule("l.city = r.city", salting_partitions=10),
            block_on("email", salting_partitions=4),
        ),
    ],
    "retain_matching_columns": True,
    "retain_intermediate_calculation_columns": True,
}


linker = Linker(df, settings, db_api)

linker.estimate_parameters_using_expectation_maximisation(block_on("first_name"))

linker.predict().as_pandas_dataframe()

[RobinL]

To do next:

Split up creator file and library file

[RobinL]

I've copied this across rather than attempt to re-use the code from the CustomLevel

That was deliberate, to reduce indirection, but i don't feel particularly strongly about this

[RobinL]

I left Or in to get tests passing, but i think there's an argument for dropping support for it: it's very rare you want to use an OR in a blocking rule because it usually results in a full cartesian product of the input dataframe being created

[ADBond]

Great, this works nicely and fits in well with the rest of the stuff we've been doing. Very nice being able to write stuff like block_on(ColumnExpression("surname").substr(1, 4))

[ADBond]

I wonder if it might be helpful to give an error here if people use the old syntax, given that this is possibly a more subtle change compared to other API tweaks?
For instance currently if you use block_on(["first_name", "surname"]) you will hit AttributeError: 'NoneType' object has no attribute 'sql_dialect' at some point once the linker is doing its thing, so it might be handy to nudge users in the right direction rather than them trying to unpick that

[RobinL]

Good point - done