release-22.1: colexecdisk: make sure to release resources in all cases

[yuzefovich]

Backport 1/1 commits from #81419.

/cc @cockroachdb/release

---

Previously, it was possible to not release some resources when external
distinct or external hash aggregator short circuit their execution
(either because of an error or because of the LIMIT on the query) in
some cases (namely, when a sort is planned on top of the external
operation to restore the desired ordering). This was the case because
the hash-based partitioner (which abstracts away the disk-backed
algorithm) wasn't added to OpWithMetaInfo.ToClose slice since there is
a sort on top of it nor was it closed by that sort.

Here is an example diagram for all the infra that is set up for the
disk-backed distinct when ordering needs to be maintained:

         diskSpillerBase (disk-backed distinct)
           |                      |
UnorderedDistinct     diskSpillerBase [1] (disk-backed sort)
                      |              |                  |
                in-mem sorter   external sorter   hash-based partitioner [2]

In this diagram, hash-based partitioner [2] is the external distinct
that is the input to the diskSpillerBase [1]. In the happy path (when
[2] is exhausted), it is Closed automatically. However, if its
execution is short-circuited, [2] will never be closed because:

• due to the way the infra was created, it was never added to the
  ToClose slice (so it will not be closed on the flow cleanup)
• diskSpillerBase [1] doesn't close its inputs
• external sorter nor the in-memory sorter end up closing [2] either
  because there are other utility operators that don't implement
  Closer interface between the sorters and [2].

As a result of not closing [2], some disk resources might be leaked.
This commit fixes the issue by making diskSpillerBase close all of its
inputs (which is a single input in the case of the disk-backed distinct
and disk-backed hash aggregator). Close is allowed to be called
multiple time, so it is ok if there happen to be other codepaths
calling it.

Fixes: #81413.

Release note: None

Release justification: low risk bug fix.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is 

[michae2]

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @cucaroach)