Update protobufs

[varun-r-mallya]

What was wrong?

Protobufs were not compiled and were out of date.

How was it fixed?

Just recompiled them and forced make to recompile them every time make all is run.

[varun-r-mallya]

@pacrob @acul71 @seetadev I am guessing this is one of the things that was slowing down our interop efforts, so I made sure that protobuf compilation happens at all re runs.

[seetadev]

@varun-r-mallya : Great, thank you so much Varun. This is fantastic. Appreciate your initiative and efforts.

Could you please document this finding and your PR in a discussion page. Interop test plans would require management of protobufs periodically. We'll keep this as project management exercise. Also, please add a newsfragment.

Thank you once again. Looking forward to seeing you, @acul71 and other key contributors take interop engineering efforts to a production stage.

[varun-r-mallya]

@varun-r-mallya : Great, thank you so much Varun. This is fantastic. Appreciate your initiative and efforts.

Could you please document this finding and your PR in a discussion page. Interop test plans would require management of protobufs periodically. We'll keep this as project management exercise. Also, please add a newsfragment.

Thank you once again. Looking forward to seeing you, @acul71 and other key contributors take interop engineering efforts to a production stage.

I've added the newsfragment.
I'll be opening a discussion on the protobuf update and I have also created a "design document" of how the EarlyDataHandler is implemented in Go, so we can keep a similar design for python as well. I'll be creating only one discussion on both of these after I'm done experimenting with changing the protobuf on noise and making sure all the required tests pass.

[seetadev]

@varun-r-mallya : Great, thank you for getting PR ready for final review + merge.

Appreciate your approach on opening a single, consolidated discussion for both the protobuf update and the EarlyDataHandler design. That will make it much easier for everyone to see the full picture and avoid having fragmented feedback in multiple places.

Thank you for preparing a design document based on the Go implementation — keeping parity with the Go design will definitely help with long-term maintainability and cross-implementation consistency in py-libp2p.

Glad you’re experimenting with the protobuf changes on noise before posting the discussion, since making sure all required tests pass beforehand will make the review process much smoother and give everyone confidence in the proposed changes.