Extend user-defined relations to include the index of time

[behnam-zakeri]

This PR re-introduces user-defined relations (sets, parameters, equations, variables) with the inclusion of sub-annual time index.
Background: The user-defined relations in the GAMS formulation do not represent index of time, which can be an issue when working on models with sub-annual time slices (see #191). For example, it is not possible to represent time slices in parameter relation_activity, which relates to the activity of technologies and must be defined at the sub-annual time level. The addition of time to existing sets and parameters means re-initializing these items, which will create backward incompatibility. Via #631 a workaround was suggested, which was implemented in PR#633. The improvements proposed in this PR could use the same workaround as #633, however, a few sets here, namely, is_relation_upper and is_relation_lower are populated in the Java Backend side, which may make re-initializing these sets impossible or complex on the message_ix side, i.e., in models.py.

Solution: Until a robust solution will be in place for re-initializing sets and parameters that are at the moment being populated at the Java side in message_ix, this PR proposes an interim solution as follows:

• creating mirror sets and parameters for adding the missing index: For example, parameter relation_activity_time is introduced as the mirror of existing relation_activity, and similarly relation_cost_time, relation_lower_time and relation_upper_time are added.
• creating mapping (or masking) sets on the fly in models.py. This includes is_relation_lower_time and is_relation_upper_time instead of existing is_relation_lower and is_relation_upper, respectively, which are produced on the Java backend.
• adding duplicate blocks of equations (RELATION_EQUIVALENCE_TIME, RELATION_CONSTRAINT_UP_TIME, and RELATION_CONSTRAINT_LO_TIME) for enhancing the mathematical formulation.

This PR remains as draft for the time being. Merging this PR in the main branch shouldn't create any problems for running existing scenarios. However, having duplicate items (set, parameter, variable and equations) proposed in this PR may not be an optimal solution from a design perspective.

How to review

1. Check out this branch and run your existing scenarios, and they should work without a flaw.
2. Load model/scenario "MESSAGEix-CAS/relations_with_time_index" from "ene_ixmp" database and solve it using the code in this PR. This scenario does include the new items proposed in this PR. There shouldn't be any error when loading and solving that.

PR checklist

• Continuous integration checks all ✅
• Add or expand tests; coverage checks both ✅
• Add, expand, or update documentation.
• Update release notes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.5%. Comparing base (d3cf5bd) to head (ec8a2bd).
⚠️ Report is 335 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #680   +/-   ##
=====================================
  Coverage   95.5%   95.5%           
=====================================
  Files         46      46           
  Lines       4340    4351   +11     
=====================================
+ Hits        4148    4159   +11     
  Misses       192     192           

Files with missing lines	Coverage Δ
message_ix/models.py	99.1% <100.0%> (+<0.1%)	⬆️
message_ix/tests/test_report.py	100.0% <100.0%> (ø)
message_ix/tests/test_tutorials.py	97.6% <ø> (ø)

[glatterf42]

#705 already includes the content of commit 08ef0c7, so when you continue working on this PR, you can/have to exclude this commit. See this comment for how to do that.

[glatterf42]

@behnam-zakeri This sounds useful to me in principle :)
The new ixmp4 backend might make changes to how subannual time values are handled -- we can only respect the behavior that's covered in the current test suite. So it might be that things will soon change in a way that makes it harder for the PR to be merged. I think it would be easier for you to finalize this PR now, which shifts the burden of maintaining compatibility to ixmp4. If you don't have the time to do that yourself right now, you can consider raising it in a weekly meeting and asking for someone's time :)