fix: Gracefully handle CardanoTokenRegistry errors during getAsset request

[ivaylo-andonov]

Context

AssetInfo.tokenMetatdata is stored in an off-chain registry, which cannot be depended on for returning a match for the given assetIds, nor it's service availability. Currently we’re rethrowing request errors as a Provider error, which is not ideal since it then couples our own service health, as opposed to the desired behaviour of omitting the metadata from the response.
cardano-js-sdk/CardanoTokenRegistry.ts at 8fe1cdd7683a7802bebd081616abead292488953 · input-output-hk/cardano-js-sdk

This issue does raise an important question of how can a client differentiate between a response that included a 404 from the registry vs a 5xx with our current shape of from AssetInfo.tokenMetadata

Proposed Solution

Approach A)
Introduce the suggested approach from the task description with minor diffs as follows:

interface TokenMetadataSource {
  type: MetadataSourceType; \\ enum to support: 'registry', 'on-chain' or 'referenced'  
  requestStatus: 'success' | 'fail'; 
}

export interface AssetInfo<Source> {
  ...
  tokenMetadata?: { data?: TokenMetadata | null, source?: Source } ;
  ...
}

// Provider interface use AssetInfo<unknown>
// cardano-services use AssetInfo<TokenMetadataSource>

Notes:

• cached: boolean is committed because it's not so related to the Source scope, however, it could be added easily with correct values within CardanoTokenRegistry easily
• source? property is nullable to keep the compatibility with the other providers which implement sameAssetProvider such as blockfrost. Not sure what source.type in blockfrost should be since the tokenMetadata is fetched as part of the whole blockfrost.assetsById() response.
• in cardano-services is used AssetInfo<TokenMetadataSource>, everywhere else is AssetInfo<unknown>
• token metadata responses are adjusted based on the interface changes within the tests (wrapper into data obj and added source obj in cardano-services)

Approach B) Omitting the metadata from the response in case of 5xx error thrown by the external source (in our current situation - token metadata server)

Following the CIP-0035 comment, the second approach could be simply to avoid the AssetInfo interface changes and to keep it as it is:
tokenMetadata?: TokenMetadata | null; with the only difference is to shallow the ProviderError in catch block and to omit tokenMetadata in case of network error by the external token server by returning simply null.

The downside here is losing the details of the source/origin of that data.

Important Changes Introduced

[rhyslbw]

Looks good so far @IvayloAndonov, just a minor change request

[rhyslbw]

Given there's currently only a single source for this metadata, let's revert the breaking AssetInfo type change given tokenMetadata === undefined can be used to infer the success of the registry request.

[ivaylo-andonov]

Rebased with master and resolved conflicts.

Revert the breaking AssetInfo type change: 039e0f0 (it eliminates most of the previously introduced changes)

[rhyslbw]

DbSyncAssetProvider test is missing the assertion that demonstrates the assetInfo.tokenMetadata value is undefined if the asset is not found in the token registry.

[mkazlauskas]

Nice work! 🚀

[ivaylo-andonov]

Rebased with master and squashed commits.