feat: Node discovery via DNS

[usmansaleem]

PR description

Fold Tuweni dns discovery module into Besu p2p discovery module. The Tuweni dns-discovery was Kotlin code using kotlin co-routines. It has been translated (and adapted) in Java. Utilized vertx worker verticle to launch dns daemon in a separate thread outside event loop. Rest of the method protocol is exactly same at the moment.

The screenshot shows mainnet peer connection for four nodes which were configured with SNAP and CHECKPOINT.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[shemnon]

I'm curious as to why this was ported to a separate Consensys lib and not folded directly into Besu. Are there other projects that use this library? Is it because it's written on Kotlin? It's only 5 production files and 2 test files if wiring in a kotlin compiler step isn't desired (surely less effort than maintaining an ongoing deployment). I't also makes it more difficult to alter the classes if features such as streaming the nodes instead of querying them all in one go is desired.

[usmansaleem]

@shemnon Hi Danno, the initial thought was just to port it as it is to make further changes and include it as a library, however, you've raised valid points, I concur that folding these classes (the dns-discovery) into besu should not be too difficult. I am not aware of any other projects using the Tuweni dns-discovery module.

@macfarla any further thoughts?

[macfarla]

@shemnon Hi Danno, the initial thought was just to port it as it is to make further changes and include it as a library, however, you've raised valid points, I concur that folding these classes (the dns-discovery) into besu should not be too difficult. I am not aware of any other projects using the Tuweni dns-discovery module.

@macfarla any further thoughts?

yeah fair point @shemnon if it's easier long term I'm not opposed to folding it into Besu. Initial thinking was we could still revert to tuweni libs again if they got updated but that also may not eventuate.

[shemnon]

As a bit more context, I'm looking at folding the tuweni-bytes libraries back into besu (undoing #215 in effect). My main reason is a tighter optmiization loop when speeding up the EVM as well as being able to purpose-build some of the bytes implementation for speed. Coordinating these changes across repos creates significant friction.

[macfarla]

is this sufficient attribution as far as the apache license is concerned?

[usmansaleem]

I think it is. Although we may have to update our NOTICE file with Tuweni's NOTICE file. Our NOTICE file is empty though. Also, we didn't do a verbatim copy of the code, we adapted and converted it into Java language from Kotlin language.

https://opensource.stackexchange.com/questions/8717/how-to-attribute-code-from-a-project-under-apache-v2-in-a-new-project

[usmansaleem]

https://github.com/tmio/tuweni/blob/main/NOTICE

[shemnon]

Do we add all contributors info to the notice going forward?

[usmansaleem]

I think if we are "reproducing" or "including" code from an Apache license project that contains a NOTICE file, it ought to be included in our NOTICE file as well. I am not sure whether we had to include NOTICE attributions from Vertx and other libraries that are included in binary form. @non-fungible-nelson FYI for your input as well.

[shemnon]

LGTM.

[macfarla]

nice