Make non-partitionable resource types configurable instead of hardcoded in BaseRequestPartitionHelperSvc

[patrick-werner]

Problem Description

Currently, HAPI FHIR hardcodes a list of resource types as non-partitionable in the class BaseRequestPartitionHelperSvc:

myNonPartitionableResourceNames.add("StructureDefinition");
myNonPartitionableResourceNames.add("Questionnaire");
// ...

This behavior prevents resource types like Questionnaire from being partitioned, even though many real-world multi-tenant deployments require exactly that (e.g. tenant-specific forms, templates, libraries, etc.).

To override this restriction, developers currently must:

• Subclass RequestPartitionHelperSvc
• Use reflection to remove "Questionnaire" from the internal Set
• Override Spring beans manually – which is brittle and unsupported across versions

This limits flexibility and increases complexity for multi-tenant environments.

Proposed Change

Introduce a first-class extension mechanism (e.g. a setter or protected method) that allows customizing the list of non-partitionable resource types without relying on reflection or deep bean replacement.

[jamesagnew]

None of the validation infrastructure is currently designed to know how to look in non-default partitions when looking up resources for validation. This change seems simple, but would need to touch the validation support layer (to ensure that we look in the right place - presumably we'd need to start passing RequestDetails down into calls to IValidationSupport in order for the partition service to be able to correctly determine the partition), the cache layer (to ensure that the cache doesn't give up data belonging to one partition to another), and possibly more.

Definitely agree that this would be great, but it's a very major change.