Fix for NPE seen when sometimes trying to clone the next state

[eedrummer]

This PR addresses Pattern 1 as reported in #1380. It makes sure that this issue should not happen, but there is still a likely underlying issue in Synthea. Whether it is worth addressing is up for debate.

The NPE in the bug report happens when the person in the simulation is going through the AVRr Referral submodule in the Myocardial Infarction module. When looking at the debugger for the case in question, Module is on the state Priority_4_Next_Encounter_2 and trying to transition to the state Valve Surgery. However, Module is in the context of the CABG Referral submodule. When it tries to find the Valve Surgery state, it isn't there.

This is likely due to both the CABG and AVRr submodules being called referral. This PR renames them so that they both have unique names. There is likely a better fix that would ensure that these two submodules don't conflict, but I was unable to pinpoint where that fix would go and this is an obvious solution that is easily implemented.

[codecov]

Codecov Report

Merging #1387 (d082b16) into master (6192ed7) will increase coverage by 0%.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master   #1387   +/-   ##
========================================
  Coverage        77%     77%           
- Complexity     3685    3696   +11     
========================================
  Files           170     170           
  Lines         24005   24005           
  Branches       3331    3331           
========================================
+ Hits          18524   18566   +42     
+ Misses         4448    4408   -40     
+ Partials       1033    1031    -2     

see 23 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[arvindshmicrosoft]

Thank you @eedrummer for your great help addressing the issue!

[dehall]

The fact that synthea could be picking the wrong submodule when there are multiple with the same name is a little scary... Does this happen more often and we just don't notice?

The approach feels good, should we take this opportunity to ensure all submodules have unique names? Across the heart surgery modules there appear to be a few more with the same name: [preoperative, postop, outcomes, medications, operative_status, operation]

[eedrummer]

Ensuring all submodules have unique names is certainly a way to avoid this.

I don't know how often this happens, but I suspect it is pretty infrequent. It's likely that there is some other condition that must be met to trigger this case. If I had to guess, it would be that the user needs to go back and forth between the submodules of the same name.

Also, for the case I worked on, the issue happened in a delay state, so the time rewind logic may also have to come into play.