Cds 421 multi adaptor intersect constraints simple

[EddyCMWF]

This is to intersect_constraints with MultiAdaptor datasets.

Approach:

• intersect_constraints in parent adaptor
• reconstruct single request from parts
• split with multi-adaptor split code
• intersect_constraints in the sub-adaptor

This duplication of intersection may be repetitive, but it prevents the possibility of creating a very large number of sub-adaptor requests which may make logging/debugging nasty.

NOTE: Leaving the possibility of mapping being applied at the parent adaptor, but this contradicts using the same constraints for both parent and child adaptors. We do not have any parent level mapping, so not a problem in practice, but for sure can enforce correct behaviour.

[ecmwf-cobarzan]

Two things to be checked:

• is the self.mapped_request after (the merge-back operation) in the same space as the constraints that are sent to the sub-adaptors? actually, what matters is if by the time the sub-adaptors do the constraints intersection the request and the constraints are in the same space (i.e. mapped or not mapped)
• would it be possible to avoid the merge-back operation, e.g. by deciding that the multi-adaptor won't split the request in any way (by not doing intersect_constraints, split-by-month or other splitting operations), but leave that to the sub-adaptors?

[EddyCMWF]

Two things to be checked:

* is the `self.mapped_request` after (the merge-back operation) in the same space as the constraints that are sent to the sub-adaptors? actually, what matters is if by the time the sub-adaptors do the constraints intersection the request and the constraints are in the same space (i.e. mapped or not mapped)

* would it be possible to avoid the merge-back operation, e.g. by deciding that the multi-adaptor won't split the request in any way (by not doing intersect_constraints, split-by-month or other splitting operations), but leave that to the sub-adaptors?

For the second part, we could avoid the merge-back operation, and just send the original request to the splitting. However, I think we still want to do the normalise_request (+ intersect_constraints) at the top level adaptor as that means we can reject InvalidRequests before they get onto a worker.

The merging of requests could be useful for the cads-obs adaptor, so I was thinking about putting it in the general tools to be used there

[EddyCMWF]

Two things to be checked:

* is the `self.mapped_request` after (the merge-back operation) in the same space as the constraints that are sent to the sub-adaptors? actually, what matters is if by the time the sub-adaptors do the constraints intersection the request and the constraints are in the same space (i.e. mapped or not mapped)

* would it be possible to avoid the merge-back operation, e.g. by deciding that the multi-adaptor won't split the request in any way (by not doing intersect_constraints, split-by-month or other splitting operations), but leave that to the sub-adaptors?

For the first part, if I understood what you mean....

The request passing to sub-adaptors has not changed. The self.mapped_request we have in multi.py is in the top level adaptor, this is then split this into X requests, each of which is sent to it's own adaptor.

The constraints handling has changed, and previously they were not in the same space, i.e. the constraints were only in the top-level adaptor but the intersection wsa in the sub-adaptor. Now we pass the constraints to the sub-adaptors, so when we intersect_constraints in the sub-adaptors we have both the request and constraints.

[EddyCMWF]

Two things to be checked:

* is the `self.mapped_request` after (the merge-back operation) in the same space as the constraints that are sent to the sub-adaptors? actually, what matters is if by the time the sub-adaptors do the constraints intersection the request and the constraints are in the same space (i.e. mapped or not mapped)

* would it be possible to avoid the merge-back operation, e.g. by deciding that the multi-adaptor won't split the request in any way (by not doing intersect_constraints, split-by-month or other splitting operations), but leave that to the sub-adaptors?

For the first part, if I understood what you mean....
The request passing to sub-adaptors has not changed. The self.mapped_request we have in multi.py is in the top level adaptor, this is then split this into X requests, each of which is sent to it's own adaptor.
The constraints handling has changed, and previously they were not in the same space, i.e. the constraints were only in the top-level adaptor but the intersection wsa in the sub-adaptor. Now we pass the constraints to the sub-adaptors, so when we intersect_constraints in the sub-adaptors we have both the request and constraints.

For the first part, what I meant is that in the multiadaptor, the mapped_request already went through apply_mapping (so it is in the data provider space/syntax), while the constraints are still in the user space/syntax. So sub_adaptors = self.split_adaptors(self.mapped_request) works with the request and constraints using different syntax? Unless the multiadaptor never does any mapping itself. This is what I wanted to be checked.

As discussed on Teams, this is a known bug/potential incompatibility (mentioned in PR description). I will open a new PR to address this specifically.

[EddyCMWF]

Additionally, moved the merge_requests function to the hcube_tools module