#8723 Fix for WMTS background issues due to attribution parameter; #8724 WMTS request identify flow fixes

[alex-fko]

Description

This PR applies minor changes to resolve following issues:
8723
8724

• WMTS background requests were failing due to attribution parameter passed to the requests. While parameter itself doesn't break anything, having html tags in it makes tile requests fail. Applied changes just making sure that attribution is used by MapStore, but not being added to the request.
• Features set displayed in identify results panels could possibly have feature with ref property. Such feature can potentially cause React exception because of props spreading in RowViewer component. With the applied changes ref property is omitted prior to spreading.
• Click outside of the tile matrix is causing GetFeatureInfo request fail with 400 error. This error was not handled properly on the side of identify flow for WMTS layer. It resulted into epic error and complete outage of side-effects processing. Applied changes adding extra check to the identify flow for WMTS layers to make sure that error is processed properly if request fails because row/column is out of range.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Issue

What is the current behavior?
8723
8724

What is the new behavior?
According to the description. Please refer to the example map/geoStory in referenced issues for testing.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

[ale-cristofori]

@alex-fko once reviewed and tested needs backporting to 2022.01.xx

[offtherailz]

Did you tested this? I'm afraid this catch will never be called because

• errors are not trown, axios will receive a standard OGC error, that has HTTP status 200.
• You are returning the Exception, or data, while catch requires to return an observable.

I'm afraid you added the code but you didn't tried it.

Something like this should work

.let(interceptOGCError) // from ObservableUtils
.catch(e => {
    // do things
    if(notManaged) { // if you can not manage exception.
         throw e;
    }
    return Observable.of({data: {features: []} } );
    // or, if not managed

});

should work. So you should add a unit test with the response and the expected result.

[alex-fko]

Why would I add exception handler without even trying it?
It can be checked using #/geostory/41714
Here it is, thrown upon click outside of the area where data is available, status code is 400:

[offtherailz]

Sorry, I didn't want to accuse of course :)
When I said "I'm afraid you added the code but you didn't tried it." I meant that you committed in error.
It is strange, usually they respond with 200. I had not data to try it, so I wasn't able to verify myself.
I will try with #/geostory/41714, thank you for clarifying
Anyway catch should return an Observable, not returning single values or error, at least returning an observable that emits these things. throw is a possibility, but depends on what it the function that uses it expect. I'll check.

[offtherailz]

Ok I tested it. Sorry my fault.
I did an error reading the code. Also returning exception I think it is ok. You can revert the changes.
Unit test should be added.

[offtherailz]

Summarising our discussion, it seems that the withPopupSupport doesn't correctly support erroring responses.
We should verify any output format and check if the solution works also on mapviewer consistently with the error expected.

[alex-fko]

@offtherailz I've added unit test to make sure it properly handles TileOutOfRange exception.
Extra check for plain text format is added to return expected response in that case; with these all three format types (plain text, json, html) works well. That's the last thing I've checked yesterday evening after exporting map from geoStory and importing it in viewer locally. Today, for some reason, I have errors on attempt to proxy responses to my local so I cannot recheck it now.

[offtherailz]

@ElenaGallo, could you please test this on DEV ? Thank you. on dev we have #/geostory/41714 to use for testing

[offtherailz]

@ale-cristofori @alex-fko told me this have to be backported to 2022.01.xx too.
Actually the release is not on zenhub anymore. So you have to remember on your own that this have to be backported to the old branch too.

[tdipisa]

@offtherailz @ale-cristofori connected issues are for bug fixes, therefore I guess these can land in 2022.02.01 and so backported to 2022.02.xx once tested in DEV.

[tdipisa]

@ElenaGallo please test the connected issues in DEV and let us know.

[ElenaGallo]

Test passed, @alex-fko please backport to 2022.02.xx.Thanks

[offtherailz]

Backport has been merged.