OPDATA-6440: Implement iTick adapter

[dskloetc]

OPDATA-6440

Description

iTick is a provider of market data. They provide websocket and rest APIs.
We need to use different API keys for data from different regions (such as Hong Kong, Korea, etc.) so to avoid managing multiple websockets per endpoint we implement separate endpoints for separate regions.
We want to provide bid/ask/mid data as well as last price data for various stocks and indices.
bid/ask data from from a different API than last price data so we also provide these through different endpoints.

Indices are all considered to be from the gb region even though they come from all over the world.

We'll probably only be using the websocket transports but having the HTTP transports helped with testing (because the websocket API doesn't provide data when the markets are closed) and so I just left them in for convenience.

Changes

1. Shared message parsing for all depth endpoints and quote endpoints.
2. Endpoints generated from hardcoded configuration.
3. Factory methods for http and ws transports used in generated endpoints.

Steps to Test

1. yarn test packages/sources/itick/test/integration/

2. # Only works during Hong Kong market hours:
   curl --silent -S -X POST http://localhost:8080 -H 'Content-Type: application/json' -d '{
     "data": {
       "endpoint": "hk-depth",
       "transport": "ws",
       "symbol": "700"
     }
   }'
   
   {
     "result": 509,
     "data": {
       "askPrice": 509,
       "bidPrice": 509,
       "midPrice": 509,
       "askVolume": 1892400,
       "bidVolume": 2012100
     },
     "timestamps": {
       "providerDataStreamEstablishedUnixMs": 1774339451160,
       "providerDataReceivedUnixMs": 1774339473054
     },
     "statusCode": 200,
     "meta": {
       "adapterName": "ITICK",
       "metrics": {
         "feedId": "{\"symbol\":\"700\"}"
       }
     }
   }
   
   # Works during all hours:
   curl --silent -S -X POST http://localhost:8080 -H 'Content-Type: application/json' -d '{
     "data": {
       "endpoint": "indices-quote",
       "transport": "rest",
       "symbol": "GER30"
     }
   }'
   
   {
     "result": 22410.35,
     "data": {
       "lastPrice": 22410.35
     },
     "timestamps": {
       "providerDataRequestedUnixMs": 1774358808710,
       "providerDataReceivedUnixMs": 1774358808917
     },
     "statusCode": 200,
     "meta": {
       "adapterName": "ITICK",
       "metrics": {
         "feedId": "{\"symbol\":\"ger30\"}"
       }
     }
   }
   

Quality Assurance

• If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant infra-k8s configuration file.
• If a new adapter was made, or an existing one was modified so that its environment variables have changed, update the relevant adapter-secrets configuration file.
• If a new adapter was made, or a new endpoint was added, update the test-payload.json file with relevant requests.
• The branch naming follows git flow (feature/x, chore/x, release/x, hotfix/x, fix/x) or is created from Jira.
• This is related to a maximum of one Jira story or GitHub issue.
• Types are safe (avoid TypeScript/TSLint features like any and disable, instead use more specific types).
• All code changes have 100% unit and integration test coverage. If testing is not applicable or too difficult to justify doing, the reasoning should be documented explicitly in the PR.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4f0fb9e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@chainlink/itick-adapter	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mmcallister-cll]

Silly q: since it's a new EA shouldn't we just bump to the latest framework version?

[dskloetc]

Silly q: since it's a new EA shouldn't we just bump to the latest framework version?

yarn new uses the version from packages/scripts/package.json.

We can definitely bump it but I didn't think it was worth the extra effort. Let me know what you want.

[mmcallister-cll]

Might as well bump to latest FW version and sanity check/rerun tests. If you encounter any issues or uncertainty, feel free to revert to this working version.

[mmcallister-cll]

A couple comments/suggestions, mostly small.

Bigger ones:

• Use of null in response
• The v11 Schema docs indicate a lastSeenTimestampNs is required, but not available on the API response, need a product/streams SME call on whether a value is needed from the EA -- a lastReceivedMessage as seen by the EA may be better than nothing
• Do we need a tick endpoint?

[dskloetc]

The v11 Schema docs indicate a lastSeenTimestampNs is required, but not available on the API response, need a product/streams SME call on whether a value is needed from the EA -- a lastReceivedMessage as seen by the EA may be better than nothing

I've started a Slack thread.

Do we need a tick endpoint?

I don't know what this is referring to.

[dskloetc]

The v11 Schema docs indicate a lastSeenTimestampNs is required, but not available on the API response, need a product/streams SME call on whether a value is needed from the EA -- a lastReceivedMessage as seen by the EA may be better than nothing

I've started a Slack thread.

It will just be derived from providerDataReceivedUnixMs or providerIndicatedTimeUnixMs.