fix(group-layer-zoom) Fixed issue with the zoom to layer visible extent appearing on group layers

[Alex-NRCan]

Description

• Improved a bit the issue [BUG] "Coordinates must be finite numbers" when zooming to layer extent #3237 without completely fixing it.
• The error happens after the zoom to layer has occurred correctly and it happens inside OpenLayers code itself. The exception thrown by OpenLayers isn't catchable by our code.
• Added the bounds in the "More information" panel in the layer details to more easily track the bounds per layer and how they behave
  • Having the bounds more clearly defined in the "More information" made us realize of issues we had with their calculations retriggering the user interface too many times and also made us realize that we were not updating the bounds if a layer was removed from a group layer (the group layer bounds wasn't reduced) and same thing when a layer was added to a group layer, the latter was never updated.
• More cleanly distinguising the schemaTag and the entryType in the store. The 2 properties were being squished into the 'type' property in the store sometimes meaning the schemaTag and sometimes the entryType. The 'type' has been removed from the store.
• Cleanup: removing obsolete code when fetching the esri-image metadata, the url tweaking that was happening was useless.
• Improved the message displayed when trying to generate an image that's too big for the service, optimizing some methods overrides and message generation in the layers classes
• Fixed an issue with the zoom to visible scale box showing/not showing at proper zoom levels, ref: 6433173f-bca8-44e6-be8e-3e8a19d3c299 with zoom level around 3.5
• Fixing some tests in the test-suite following unexpected changes in the services which were causing false positives in our runs

Fixes #3237 partially, more information on the issue

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Released Feb 24 @ 16h15 : https://alex-nrcan.github.io/geoview/
Released Feb 25 @ 10h30 : https://alex-nrcan.github.io/geoview/
Released Feb 25 @ 14h50 : https://alex-nrcan.github.io/geoview/

Checklist:

• I have build (rush build) and deploy (rush host) my PR
• I have connected the issues(s) to this PR
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have created new issue(s) related to the outcome of this PR is needed
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

---

This change is 

[Alex-NRCan]

@Alex-NRCan reviewed 21 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Alex-NRCan).

[jolevesq]

@jolevesq reviewed 20 files and all commit messages, and made 2 comments.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on Alex-NRCan).

---

packages/geoview-core/src/core/components/layers/right-panel/layer-details.tsx line 568 at r1 (raw file):

    // Check if we can set the resource url
    if (url) {
      switch (type) {

Cleaner with schemaTag because type is restricted key word

---

packages/geoview-core/src/core/components/layers/right-panel/layer-details.tsx line 616 at r1 (raw file):

        <Collapse in={isInfoCollapse} sx={sxClasses.layerInfo}>
          <Box>{`${t('layers.layerType')}${localizedTypeName}`}</Box>
          <Box>{`${t('layers.layerBounds')}${bounds}`}</Box>

Should we put the projected values (easier to read?)

[jolevesq]

@jolevesq reviewed 1 file.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on Alex-NRCan).

[Alex-NRCan]

@Alex-NRCan reviewed 14 files and all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on Alex-NRCan).

[Alex-NRCan]

packages/geoview-core/src/core/components/layers/right-panel/layer-details.tsx line 616 at r1 (raw file):

Previously, jolevesq (Johann Levesque) wrote…

Should we put the projected values (easier to read?)

At the same time, the goal of this was to show what's in the store and what's being used for calculations and the ui 🤔

[Alex-NRCan]

@Alex-NRCan reviewed 6 files and all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on jolevesq).

[jolevesq]

@jolevesq made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on Alex-NRCan).

---

packages/geoview-core/src/core/components/layers/right-panel/layer-details.tsx line 616 at r1 (raw file):

Previously, Alex-NRCan (Alex) wrote…

At the same time, the goal of this was to show what's in the store and what's being used for calculations and the ui 🤔

The big question we asked ourselves before is it for us or the user...

We always have a way to see the store if we need. This bound value even in lat-long will be helpful. We can raise the question with Damon

[jolevesq]

@jolevesq reviewed 19 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on Alex-NRCan).

---

packages/geoview-core/src/geo/layer/layer.ts line 141 at r5 (raw file):

export class LayerApi {
  /** A zoom level buffer to guarantee that the calculations being done via the resolutions, inches per meter, dpi are more strict than not enough */
  static readonly MIN_MAX_ZOOM_LEVEL_BUFFER = 0.21;

Do we stick to this layer buffer or we go a bit wider like .3 to maybe catch more?

[jolevesq]

@jolevesq reviewed 8 files and all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on Alex-NRCan).

[Alex-NRCan]

@Alex-NRCan reviewed 8 files and all commit messages, and made 2 comments.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on jolevesq).

---

packages/geoview-core/src/core/components/layers/right-panel/layer-details.tsx line 616 at r1 (raw file):

Previously, jolevesq (Johann Levesque) wrote…

The big question we asked ourselves before is it for us or the user...

We always have a way to see the store if we need. This bound value even in lat-long will be helpful. We can raise the question with Damon

I'll add both in the ui, that way we cover our bases and it's clear

---

packages/geoview-core/src/geo/layer/layer.ts line 141 at r5 (raw file):

Previously, jolevesq (Johann Levesque) wrote…

Do we stick to this layer buffer or we go a bit wider like .3 to maybe catch more?

I understand the desire to increment it a bit more, but let's see how this goes instead of going overboard right away.