Better support forcing the write database instance

[RealOrangeOne]

What is the context of this PR?

In #425, a race condition was fixed where data created would not be immediately available. This is likely because the replica instances had not synced the relevant data yet. The fix is to force the write instance to be used for the subsequent query.

Unfortunately, there's little which can be done about this lag. In the case of #425, the queries are already using bulk_create / bulk_update, so they'll be done in a single operation, and should be synchronised at once. Therefore, trying to batch them in a transaction is unlikely to help.

Since this pattern is likely to come up semi-often, I've written a small force_write_db_for_queryset helper to make it clearer why .using is being called. I've modified the dataset view to use the force_write_db_for_queryset helper, but only when necessary, so that most cases can still use the replica instances. I've also added force_write_db to work for an entire block, and added it to the publishing management commands

The docs now reference these methods exclusively, rather than working around it with explicit .using calls (which can be unclear) or using a transaction (which has a performance overhead). DEFAULT_DB_ALIAS is the default for transaction.atomic, so that can be removed.

I've also added a test around nested transactions (ie savepoints), to confirm that definitely works.

How to review

Note that this PR contains both CMS-1000 and CMS-1001, due to the huge overlap in functionality.

Follow-up Actions

N/A

[RealOrangeOne]

Converting back to draft to include CMS-1000.

[MaciekBaron]

Just two nit-picks, otherwise LGTM!

[sanjeevz3009]

Apart from the comments left already. LGTM!

[MaciekBaron]

Marking as "changes requested" as we still have those two nit-picks I left (sorry!)

[RealOrangeOne]

@MaciekBaron Both should be fixed - I've just commented the relevant commits