We've had cases reported of read-resource calls that cover large amounts or all of the resource tree using excessive peak memory. The algorithm needs to be updated to reduce peak memory use.

1) The biggest issue is operation execution is broken down to a series of steps (AbstractOperationContext$Step) that form a chain, and each step retains various state in order to allow it to handle any operation rollback and report the overall outcome for that step. But a step that does nothing but reads and uses the default no-op ResultHandler will not need the vast majority of that state, so we should work out how to let it be garbage collected while the operation is still executing.

2) Another issue is ReadResourceAssembly handler is copying ModelNode trees into the overall result node it is assembling, but it retains a ref to the copied-in node. Solving the first issue will allow the whole handler instance to be gc'd, but for very large reads, where the trees being copied in can be large, removing the ref to the copied in node immediately will allow it to be gc'd even earlier.

3) A third issue is ReadResourceAssemblyHandler copies any FilteredData.toModelNode() output into its response node. This information is only useful for the top level handler; for any child resource the data is just discarded, but not until the top level handler does it's assembly work and clears its state. If RBAC is enabled and the caller is not allowed to see a lot of data (e.g. caller is in Monitor role), the accumlated wasted memory can be very large. So don't copy such info into the response node for child resources.