Fix/pathway browser redirects

[el-rabies]

Change Summary:

• Fixed double click on reacfoam cell
• Resolved tool-tips position issue
• Resolved issue where certain diagrams wouldn't display
• Removed reaction diagram from details tab
• Fixed breadcrumb home button redirect

[autofix-troubleshooter]

Hi! I'm the autofix.ci troubleshooter bot.

It looks like you correctly set up a CI job that uses the autofix.ci GitHub Action, but the autofix.ci GitHub App has not been installed for this repository. This means that autofix.ci unfortunately does not have the permissions to fix this pull request. If you are the repository owner, please install the app and then restart the CI workflow! 😃

[EliotRagueneau]

• Reaction diagrams are no longer part of the document ✅ , but still part of the TOC on the right, you probably want to change that
• Some diagrams are still broken, seems like which ends is pointing (needs to have an arrow head) is incorrect:
  • http://localhost:4200/PathwayBrowser/R-HSA-112307?path=R-HSA-112316&tab=details
  • http://localhost:4200/PathwayBrowser/R-HSA-1296071?path=R-HSA-112316&tab=details
• Going back home (to reacfoam) from a diagram freezes the page (can be reproduced by clicking on the little home in the breadcrumbs while being in a diagram), didn't used to happen before the integration in the website, might be something related to the lazy loading of the dependency somehow. Is fixed with the following snippet in ReacfoamComponent, but shouldn't be necessary to use a setTimeout there when it used to work. Might need to work with Stanislaw to understand what's going on there, but seems rather hard to reproduce as a context. From what I could see, the issue is not the data being empty, nor the container not being the right one, but somehow in this new infrastructure, Foamtree needs a bit more delay between Object creation and data initialization, otherwise it get stuck in an endless loops

    effect(() => { // Initialise
      if (!(this.reacfoam.data() && this.foamTree())) return; // Set data whenever it is updated
      setTimeout(() => {
        this.foamTree().set('dataObject', {groups: this.reacfoam.data()!})
      })
      if (untracked(this.correctedSelectedId)) { // Initial select
        this.foamTree().select({groups: untracked(this.correctedSelectedId), keepPrevious: false}) // Preselect the group before relaxation happens to have the selection indicator during relaxation
      }
    });

[el-rabies]

[ ] Going back home (to reacfoam) from a diagram freezes the page (can be reproduced by clicking on the little home in the breadcrumbs while being in a diagram), didn't used to happen before the integration in the website, might be something related to the lazy loading of the dependency somehow. Is fixed with the following snippet in ReacfoamComponent, but shouldn't be necessary to use a setTimeout there when it used to work. Might need to work with Stanislaw to understand what's going on there, but seems rather hard to reproduce as a context. From what I could see, the issue is not the data being empty, nor the container not being the right one, but somehow in this new infrastructure, Foamtree needs a bit more delay between Object creation and data initialization, otherwise it get stuck in an endless loops

I am not able to replicate this issue.

[el-rabies]

Some diagrams are still broken, seems like which ends is pointing (needs to have an arrow head) is incorrect:

* http://localhost:4200/PathwayBrowser/R-HSA-112307?path=R-HSA-112316&tab=details

* http://localhost:4200/PathwayBrowser/R-HSA-1296071?path=R-HSA-112316&tab=details

I can't seem to figure this issue out. Not exactly sure what is causing the problems in these arrows when other diagrams seems to be working fine. Any ideas @EliotRagueneau ?

[adamjohnwright]

Closing -- the two still-relevant changes from this branch were cherry-picked onto main in 79e2a8e (the nodeP/reactionP edge fallback in diagram.service.ts + dropping the orphaned 'Reaction Diagram' TOC entry). The description-tab arrow-function form was already on main from another commit; the Docker setup is now in the repo via a different path; the other items in the original description either don't appear in the diff or have been addressed independently. Thanks @el-rabies! See main for the merged behaviour.