add discoveryV5 functions

[richard-ramos]

Adds the following new items to go-waku c-bindings:

New config items:

• discV5: Enable DiscoveryV5. Default false

• discV5BootstrapNodes: Array of bootstrap nodes ENR Example (these values can be obtained from fleets.status.im):

  "discV5BootstrapNodes": ["enr:-M-4QCtJKX2WDloRYDT4yjeMGKUCRRcMlsNiZP3cnPO0HZn6IdJ035RPCqsQ5NvTyjqHzKnTM6pc2LoKliV4CeV0WrgBgmlkgnY0gmlwhIbRi9KKbXVsdGlhZGRyc7EALzYobm9kZS0wMS5kby1hbXMzLndha3V2Mi50ZXN0LnN0YXR1c2ltLm5ldAYfQN4DiXNlY3AyNTZrMaEDnr03Tuo77930a7sYLikftxnuG3BbC3gCFhA4632ooDaDdGNwgnZfg3VkcIIjKIV3YWt1Mg8", "enr:-Nm4QLHYoJ5WYQoVzyqPR-pwIeQvi3ONWs-EPwk3uUiBiDseN9Dd7fYbCvkMdeXcuZ-8U9IYdGm38VxSDf_Oq3zZ0cEBgmlkgnY0gmlwhGia74CKbXVsdGlhZGRyc7g6ADg2MW5vZGUtMDEuZ2MtdXMtY2VudHJhbDEtYS53YWt1djIudGVzdC5zdGF0dXNpbS5uZXQGH0DeA4lzZWNwMjU2azGhA1giYsmWV9r2yJZYAiMGHJfjLlLeqAuTAokUGPN__pkxg3RjcIJ2X4N1ZHCCIyiFd2FrdTIP", "enr:-Nm4QC0_ClHzbsutYzgT3jJm7ZY1D4shylAdd6Ac-L4uwAUha1oHM0zwoEkTORVt94W5Cpa0IiyrTcXAYLgpRXpVNUsBgmlkgnY0gmlwhC_y0kmKbXVsdGlhZGRyc7g6ADg2MW5vZGUtMDEuYWMtY24taG9uZ2tvbmctYy53YWt1djIudGVzdC5zdGF0dXNpbS5uZXQGH0DeA4lzZWNwMjU2azGhAhAm-P4q6mWONKcGnbLPU8WXZJ4Qs3AxIbrycvc7PVKsg3RjcIJ2X4N1ZHCCIyiFd2FrdTIP"]

• discV5UDPPort: UDP port for DiscoveryV5 Default 9000

New functions

extern char* waku_discv5_start()

Starts the DiscoveryV5 service to discover and connect to new peers

Returns

A JsonResponse. If the execution is successful, the result field is set to true.

For example:

{
  "result": true
}

extern char* waku_discv5_stop()

Stops the DiscoveryV5 service

Returns

A JsonResponse. If the execution is successful, the result field is set to true.

For example:

{
  "result": true
}

See: https://github.com/waku-org/go-waku/pull/400

[bacv]

Slight inconsistency in the waku api was discovered when using discv5:

• When a node is initialised with discv5 enabled, it just "mounts" the discv5 and discv5 needs to be started separately with node.discv5_start().
• When node.stop() is called, it stops discv5 internally.
• If node.discv5_stop() is called before node.stop() then a subsequent node.stop() makes go-waku panic, but waku-bindings keeps waiting for a function to return.

Leaving this here as we might want to add some notes regarding this functionality or make changes to the api.

[danielSanchezQ]

Slight inconsistency in the waku api was discovered when using discv5:

• When a node is initialised with discv5 enabled, it just "mounts" the discv5 and discv5 needs to be started separately with node.discv5_start().
• When node.stop() is called, it stops discv5 internally.
• If node.discv5_stop() is called before node.stop() then a subsequent node.stop() makes go-waku panic, but waku-bindings keeps waiting for a function to return.

Leaving this here as we might want to add some notes regarding this functionality or make changes to the api.

@richard-ramos are you aware of this? ^^^^

I think either we make it automatic, so when enabling discv5 the service is auto started/stoped. Or it need to be started/stoped manually be the caller.

[richard-ramos]

I did not know. I can work on a fix - would you prefer discv5 is automatically started/stopped? should simplify the API for sure.

[danielSanchezQ]

@richard-ramos yeah, I would say that is better that if enabled, then the service is started and stopped automatically and that's all.