fix: handle neynar responses + add additional information

[robpolak]

What changed? Why?

1. Refactored neynar client out of the ./src/core code-path.. I did this for better composability and testability.
   2. Added a neynar client which will allow for extensions without a kitchen sink class (e.g. see how we inject the user API).
   3. Added a neynar integration test to ensure our lookups are working as expected.
2. Added a concept of integration tests where we can assert the actual values coming back from neynar. I decoupled these from unit tests as we should not commingle.

Integration tests: yarn test:integration

 yarn test:integration                                                    
 PASS  src/internal/neynar/neynar.integ.ts
  integration tests
    ✓ bulk data lookup should find all users (170 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.612 s, estimated 2 s
Ran all test suites.

Unit tests : yarn test

❯ yarn test                                                                
 PASS  src/core/getFrameMetadata.test.ts
 PASS  src/core/getFrameValidatedMessage.test.ts
 PASS  src/internal/neynar/user/neynarUserFunctions.test.ts
 PASS  src/core/getFrameAccountAddress.test.ts

Test Suites: 4 passed, 4 total
Tests:       8 passed, 8 total
Snapshots:   0 total
Time:        2.856 s, estimated 3 s
Ran all test suites.

Notes to reviewers

How has it been tested?
See unit test runs above

[cnasc]

QQ: would we be better off with the official SDK? Implementing our own client on top of their HTTP api is more work than we might want to do over the long run.

One con to using the SDK would be that the bundlesize is a bit high: https://bundlephobia.com/package/@neynar/nodejs-sdk@1.7.0 though because this would be running server-side it's not as big a deal cc @Zizzamia

[robpolak]

I would be open to it.. looks like most of the library is auto-generated.. I wanted to keep our imports lightweight, but it is a great question on future support / extensibility.

[Zizzamia]

I wonder if we should create a new instance of NeynarClient() everytime getFrameAccountAddress is called.

So far it seems we are doing:

• someone might use getFrameAccountAddress multiple times
• each time a new neynarClient instance is created from NeynarClient
• each time a new this.user instance is created from NeynarUserFunction(apiKey);

So my personal feeling after reading this three times, I think we should avoid using Classes just because:

1. anytime new is run in JS it has some hidden memory and cpu cost that I would like to avoid from our side
2. all the data generated it feels gated inside an instance
3. the user will abuse our funtion, so every small code weakness will become extra big publically, so beacuse 1 and 2, this feels a bit worry to me.

@robpolak would you be ok to rewrite this as Functional-oriented instead of Class-oriented?
Also as mention over our sync, let's use utils as folder instead of internals.

[robpolak]

classes have been purged.. it does make testing much easier.

[Zizzamia]

Dope, reading the PR now

[Zizzamia]

nit. for next PR, we can probably have Fetch Error shared in a utils/network folder internal utils.

[Zizzamia]

Out of curiosity, is integ the new way folks call e2e?
I am not agaist that, I am just curios as I never saw this prefix before.
cc @robpolak @cnasc

[Zizzamia]

nit. for follow up PR, let's have more docs in here to explain what's going on.

Also let's try to keep the internal architecture as flat as possible, so that instead of having src/utils/neynar/user/neynarUserFunctions.ts we just have src/utils/neynar/neynarUserFunctions.ts as it will make it easier to understand for folks reading and contributing back.

[Zizzamia]

LEGEND

Just left a few notes for a follow up PR.