Fix force_derivation bug

[sloosvel]

Description

This PR adds a check that does not allow to combine force_derivation: false and wildcards in the timerange tag and should the previous force_derivation: false behaviour.

Closes #1626

Link to documentation:

---

Before you get started

• ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• 🧪 The new functionality is relevant and scientifically sound
• 🛠 This pull request has a descriptive title and labels
• 🛠 Code is written according to the code quality guidelines
• 🧪 and 🛠 Documentation is available
• 🛠 Unit tests have been added
• 🛠 Changes are backward compatible
• 🛠 Any changed dependencies have been added or removed correctly
• 🛠 The list of authors is up to date
• 🛠 All checks below this pull request were successful

---

To help with the number pull requests:

• 🙏 We kindly ask you to review two other open pull requests in this repository

[sloosvel]

Pending to improve the code coverage.

[codecov]

Codecov Report

Merging #1627 (659b44a) into main (12f679a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1627   +/-   ##
=======================================
  Coverage   91.38%   91.38%           
=======================================
  Files         204      204           
  Lines       11172    11173    +1     
=======================================
+ Hits        10210    10211    +1     
  Misses        962      962           

Impacted Files	Coverage Δ
esmvalcore/_recipe.py	95.91% <100.00%> (+<0.01%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 12f679a...659b44a. Read the comment docs.

[schlunma]

Thanks for these quick changes Saskia, everything works fine now!!

One question: While testing this I realized that our data finder struggles to find data when the number of digits for the start year is longer than the number of digits of the end year (e.g. timerange: 200001/2001). The reason for this is that the comparison used to check if a file lies within the given timerange (start <= time_in_file <= end) never returns anything since the integer 200001 is never smaller than the integer 2001.

I don't think we can easily fix this in a general way, as padding these numbers automatically is quite dangerous (e.g., we also have 3-digit years, and can probably also have 5-digit years, in which cases an automatic padding would be plainly wrong).

I would suggest that we add a note to the doc that users need to be carefulhere and specify the same number of digits for the start and end period. Can I simply push this to this branch here? Thanks!!

[sloosvel]

I am not sure how this is related to this pull request, but if clarifying this is useful to you, please add the comments as needed.

[schlunma]

The problem I encountered was that I got missing data errors when using timerange: */2000 for a dataset even though the data is there. Turns out the wildcard is resolved to 197901/2000 in this case, thus leading to the problem described above.

[sloosvel]

amazing, please push whatever is needed to the branch and approve it so it can be merged!