Should `hpindex` be saved and read from `*.rh*` files?

I found an issue with ELM that maybe also applicable to CTSM. Let me describe the issue:

1. ELM simulation was performed with hash-x and restart files were saved.
2. To hash-x, few code modifications were applied that included the addition of a new optional field via `hist_addfld1d = ( ..., ..., default='inactive')`. Let's call the new code at hash-y.
3. When a new case is created with hash-y with `CONTINUE_RUN=TRUE` using restart files from step-1, the code crashes.

The code crashes because of it reads `hpindex` from `*.rh*.nc` and below is my explaination why this is happening:

1. During the initialization of the continue run, history fields are set up via [htapes_fieldlist()](https://github.com/ESCOMP/ctsm/blob/master/src/main/histFileMod.F90#L624). During this stage, the `hpindex` for each field is correctly assigned after accounting for a new optional field.

2. But, [`hist_restart_ncd`](https://github.com/ESCOMP/ctsm/blob/master/src/main/histFileMod.F90#L3548) overwrites `hpindex`, which are read from `*.rh*.nc` at [histFileMod.F90#L4092](https://github.com/ESCOMP/ctsm/blob/master/src/main/histFileMod.F90#L4092). This overriding of `hpindex` messes up the memory allocated in `clmptr_rs` for various fields.

If I comment out the code on ~[histFileMod.F90#L4092](https://github.com/ESCOMP/ctsm/blob/master/src/main/histFileMod.F90#L4092)~ [histFileMod.F90#L4094](https://github.com/ESCOMP/ctsm/blob/master/src/main/histFileMod.F90#L4094), the code runs successfully. Thus, I'm wondering if there is a reason for saving and reading `hpindex` from `*.rh*` files.