This is a significant effort to move to a solution which (at best) has feature parity with our current approach. I agree with Juraj's assessment from the 1/24 DTS meeting that the cost/benefit of this work right now is not compared to other tickets. So, in my view this can be deprioritized or dropped altogether. But, just making the ticket anyways so that our meeting topics are represented here and anyone can chime in if they want.
I have been working on an implementation to replace the XML-RPC server and I have managed to functionally send and receive packets using scapy. The only side note is that I wasn't able to use a scapy interactive shell directly due to an issue I have been hitting with IPython where the interactive_remote_session doesn't support Cursor Position Requests (CPR) which hinders output collection. I can, however, use an underlying interactive python shell and simply do a: `from scapy.all import *` which, to my knowledge, creates a functional replica of the interactive terminal you would get if you ran the command `scapy` on the command-line. Doing this should expose all of the functionality of the library and, even if it weren't a 1:1 copy of the scapy terminal, it should still be more than we need. The XML-RPC server itself is also limited by the functionality of the scapy library that is exposed to python, so doing this using a python shell does not limit us anymore than the potential/theoretical limitations that exist in the current framework.