Refactor block_using_rules_sql to follow normal pattern and avoid confusion

[RobinL]

Type of PR

• BUG
• FEAT
• MAINT
• DOC

Is your Pull Request linked to an existing Issue or Pull Request?

This pr revealed a mistake I made in blocking.block_using_rules_sql whereby the function was not a pure function that returned just SQL.

Instead, it the case of a _two_dataset_link_only it was running _enqueue_sql - a side effect that means this sql gets 'lost' if you look at the results of the function.

This is contrary to the pattern elsewhere in the codebase where, if multiple tables need queuing, then the function should return a list of sql statements. This pattern is used everywhere we see code like:

for sql in sqls:
        linker._enqueue_sql(sql["sql"], sql["output_table_name"])

Give a brief description for the solution you have provided

I've adjusted block_using_rules_sql to be block_using_rules_sqls.

Think it's a good idea to get this merged before #1664 to try and keep additional complexity to a minimum

[ADBond]

Looks good 👍

[ADBond]

I wonder if maybe the fact that we use

for sql in sqls:
        linker._enqueue_sql(sql["sql"], sql["output_table_name"])

so many places means we could probably do with a shortcut helper, but that is probably best left as a separate one-and-done task across the codebase. Will open an issue

[RobinL]

Thanks!

Yeah agreed, would make sense to have a _enqueue_multiple_sqls