feat!: configurable transport service and remote enr

[acolytec3]

Adds the following:

• Adds a transport option to Discv5.create to all an alternative transport layer to be used by the SessionService provided it implements the ITransportLayer interface and falls back to the native UDP implementation
• Adds a new optional remoteEnr parameter to the sendTalkReq/sendTalkResp to allow an ENR to be passed into these two message handlers since Portal Network maintains its own routing tables outside of the base discv5 routing table and our tables may contain ENRs that are not found in the base discv5 table.
• Adds a hack enableLogs to allow the debug logs to be displayed in the browser. I'm open to alternative ways of handling this one but not sure what the options are. I believe this actual suggestion came from @wemeetagain. If you don't like this method in the interface, presumably I should be able to somehow override the default logger from within our portalnetwork module so we can still surface the discv5 logs at the Portal Network level.

I've tested all this locally with our portal network module and it seems to work well.

[mpetrunic]

LGTM, @wemeetagain when merging, change the commit message because for "one commit PR" GitHub will prefer commit name rather then PR title (that's why semantic CI is failing)

[wemeetagain]

I think we can change the interface here to be more aligned with what we need to send an Rpc request/response. (Also replace Buffer with Uint8Array.) I'm thinking something like this:

public async sendTalkReq(dst: ENR | Multiaddr, payload: Uint8Array, protocol: string | Uint8Array): Promise<Uint8Array> {
  return await new Promise((resolve, reject) => {
    this.sendRpcRequest({
      contact: createNodeContact(dst),
      request: createTalkRequestMessage(payload, protocol),
      callback: (err: RequestErrorType | null, res: Uint8Array | null): void => {
        if (err !== null) {
          reject(err);
          return;
        }
        resolve(res as Uint8Array);
      },
    });
  });
}

We can also expose findEnr as a public method, so anyone who wants something like the existing situation can find the enr themselves.

const enr = discv5.findEnr(dstId);
if (!enr) {
  throw ...;
}
const resp = await discv5.sendTalkReq(enr, payload, protocol);

And then we can have a similar interface/implementation for sendTalkResp

[acolytec3]

So make the consuming app provide the ENR up front and remove the ENR lookup entirely from within sendTalkReq (and friends)?

[wemeetagain]

Yeah!

[mpetrunic]

isn't that gonna be breaking change?

[wemeetagain]

Yeah, it is. If we want the other stuff in the current version, we can break this up into another PR.
Afaik, lodestar and ultralight are the only users of this library, moving quickly to another version shouldn't be an issue.

[acolytec3]

I've pushed requested changes. I wasn't sure the best way to handle the sendTalkResp changes so take a peek and let me know what you think.