@zimri-leisher want to take a look?

Awesome, thanks for figuring out the issue!

@zimri-leisher I think this is now done. Here is a summary of the decisions and changes I made:

1. reconnect -> reopen as specifically the code is reopening a socket. This change makes all of the language of the SDDs more understadable.
2. start no longer accepts a reconnect/reopen flag. Since this property affects the component in both send and recv I decided it did not belong in the start call. The start call now looks identical to other threads.
3. configure on UDP now asserts. The user must call the configureSend/configureRecv variants explicitly.
4. I am keeping the simplified loop break behavior.

Let me know if you like these changes, 2 and 3 will require some users to update code.

@zimri-leisher this work should be ready. Would you mind reading the summary and let me know any more comments?

@thomas-bc would you do the official review?

Sorry for the late response. 1 and 2 are great! 3 is interesting, it makes sense to me, but generally when things like this happen (a class has a method that should not ever be called), it's pointing towards a larger issue with the class hierarchy. I think this is a fine fix for now, but maybe in the future the socket class hierarchy could be simplified into a more linear, C-style layout (depth-one or -zero inheritance, and helper libraries of static functions). I think most of the problems we're facing, and code that's confusing, is just us fighting abstraction that could be removed altogether. I will keep this in mind for future contributions to FPrime. Finally, I agree with 4.