Test case: using custom decoder

[balanza]

Description

This PR introduces no changes but a failing test. It serves to demonstrate the existence of a bug spotted in pagopa/io-app#2717. It adds 2 test:

1. using a custom decoder by passing it as an explicit <statusCode, responseDecoder> map
2. using a custom decoder by passing with an implicit interface, assuming it's going to be mapped to the default success status code.

Results

While the first test passes, the second fails. I understand this happens because the generated requestTypes modules ships a function isDecoder which is wrong in determining if the value passed is a decoder or a map of decoders; by failing this, it erroneously treat a single decoder as a map of decoders, hence the bug.
Here the implementation.

Proposed solution

provide a working isDecoder implamentation

Mitigation

Just use an explicit decoder map.
Please note that, given a aCustomDecoder decoder and a request with status as a default success status code, the following two instructions build the very same response decoder:

const responseDecoderA = myRequestDecoder(aCustomDecoder);
const responseDecoderB = myRequestDecoder({ [status]: aCustomDecoder });

How Has This Been Tested?

E2E test suites

[balanza]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[pagopa-github-bot]

	Warnings
⚠️	Please include a Pivotal story at the beginning of the PR title (see below).

Example of PR titles that include pivotal stories:

• single story: [#123456] my PR title
• multiple stories: [#123456,#123457,#123458] my PR title

Generated by 🚫 dangerJS