NIP-66/115 support

[dskvr]

help needed

• Where is the correct location for the geotags stuff? Intuitively this would be a mixin or similar, but see no existing patterns. Presently extending a new class that extends NDKEvent inside kinds/nip66 but this is clearly not right.

todo

• squash initial history
• accidentally committed lock file, revert before squash
• accidentally committed changes to content-tagger.ts, revert before squash
• relay-monitor.test.ts
• relay-discovery.test.ts
• relay-meta.test.ts
• add mocks for async methods in relay-monitor.test.ts
• Monitor discovery ... it's not a kind, don't know appropriate location, static methods inside RelayMonitor.ts? An NDKRelayMonitor class that implements NDKUser, NDKRelayLists and NDKProfile?
• RelayMonitor fetches
  • add tests for RelayMonitor fetches
• fix GeoCodedEvents (if needed)
  • add GeoCodedEvents.test.ts
• squash

depends on nostr-protocol/nips#230
depends on nostr-protocol/nips#952

[dskvr]

Leaning towards extracting fetchers from RelayMonitor (relay discovery and meta fetchers) and the entire NDKRelayMonitors (monitor discovery) from this PR.

Rationale:

• To obtain a full dataset of relays would most likely require multiple subscriptions due to the dataset being larger than the average max_events value of most relays. (like nostr-fetch does)
• The coverage over NIP-66 in this PR is not necessary to be included in NDK, as this coverage bloats the package far too much for an auxiliary kind that may take some time to be incorporated into clients and internal functionalities such as outbox

Certain methods, such as the NIP-66 filter generation and a flexible fetcher would remain in this PR. The helper methods are what I am targeting to externalize to another library that implements NDK, likely via nostr-fetch

[erskingardner]

Is this PR still active @dskvr ? There is one task left in the list above so I'm not sure if I should review or not?

[dskvr]

@erskingardner Never received any feedback on that item so couldn't finish it.

I'm probably going to move most functionality into an NDK extension, because NDK does not natively support fetching of a full dataset and full coverage over NIP-66 would needlessly bloat NDK.

Edit
What would remain in this PR is the NIP-66 event kinds that extend NDKEvent (less the fetcher methods they contain!)

I can update this PR to reflect the updated, previously expressed scope of NIP-66 in NDK. Changing PR to draft.