[CEP] Make Host -> Extension auto-closing a configurable behavior

[ctsims]

Abstract
HQ tries to be helpful by auto-closing extension cases when host cases are closed, but this behavior isn't always desirable so it would be useful for it to be configurable at some level.

Motivation

Background
On the platform level, when a Case which has extensions is closed, by default the sync algorithm will remove both the Case and the Extension from the user's "sandbox". From the user's perspective, it is as if all of the cases are 'closed' even though only the "Host" case actually has its closed field set.

This behavior is implicit in the sync algorithm, rather than explicitly relying on all cases to be physically closed in a transaction, because extension cases can be distributed between offline users, so new extensions created on another device in between a sync and the host case closure could end up still open and synced.

However, in many projects projects use the "closed" status on cases for reporting, and the fact that the extension cases appear "closed" (IE: Don't show up) for end users, but don't have their "closed" status set on the case is confusing. To address this, HQ performs a close_extensions transaction during case processing which closes existing extensions when their host is closed.

New Desired Behavior
One set of projects is seeking to use extension relationships in a way that more closely maps how they work in the platform without auto-closing, since both the Host and Extension cases will be actively used regardless of whether the other is closed.

Specification
I believe this should be as easy as making this specific processor dependent on a project level configuration.

Another approach would be to make the behavior dependent on the initial case close transaction itself, but I don't favor this option for a few reasons, including the simplicity of the change.

Impact on users
This will require HQ to do an extra read on some model (wherever the config is stored) during form/case processing. Depending on where that config is stored and how cache-able the check is, it could increase processing time, especially since it's common for big bulk operations to be handled in this part of processing.

Especially if the configuration source to be pulled is a couchdoc for the domain, this could be a meaningful increase in latency, so we should make sure that is evaluated or cached.

Backwards compatibility
Since the current behavior is already active, any checks introduced will need to assume that 'no configuration set" is interpreted in the same way that it is today. This is simple if the config is set at a project space level, but much more complex if it needs to be set at the Case Close Transaction level.

[millerdev]

No objections on first pass. Agreed that load latency/cacheability is an important concern. It would not be surprising to me if we were already loading the domain (or cached settings from it) somewhere in the submission process.

[snopoke]

#28998