Networking/Filesystem: add 9P2000 network file client.

[IamPete1]

This allows AP to access network storage. This implements a full set of filesystem functions. Future work would be to allow logging to and loading scripts.

This has only been tested in SITL so far, some more work is needed to get this working on real hardware (mostly just fixing the compiler warnings). It would be good to more to more union/structure based packing rather than lots of memcpy-ing. But there are some slightly tricky variable length fields. There are also loads of internal errors here to catch issues, we may want to deal with in a better way. This is also a blocking, not for use in the main thread.

9P2000 docs are a bit thin on the ground, there is this: https://ericvh.github.io/9p-rfc/rfc9p2000.html and https://www.usenix.org/legacy/event/usenix05/tech/freenix/full_papers/hensbergen/hensbergen.pdf.

I have been testing against a server hosted with: https://github.com/knusbaum/go9p

Note that this is client only. You cannot access the AP file system remotely, the point is that you use a external file system in the first place which you can accesses remotely without AP slowing things down.

[IamPete1]

Tested on CubeRed, works the same as SITL.

[peterbarker]

Suggested change

	('AP_NETWORKING_FILESYSTEM_ENABLED', r'AP_Networking::NineP2000::init'),
	('AP_NETWORKING_FILESYSTEM_9P2000_ENABLED', r'AP_Networking::NineP2000::init'),

[davidbuzz]

"diod" is another impl...
https://github.com/chaos/diod/tree/master
... and it includes a good protocol.md
https://github.com/chaos/diod/blob/master/protocol.md

[IamPete1]

Some bench marking with the new script, although I'm not sure how much I trust lua with writing larger block sizes. It just assumes that the write worked and does some buffering. For reads we know the length of the data returned so the script deals with incomplete results.

• Read and write speeds are very similar, the network cost is the same, the underlying storage speed on the server is negligible in comparison.
• Almost constant time, so bigger blocks boost the data rate. Small block sizes result in terrible data rates.
• Nothing above 4096 bytes worked reliably, I'm not sure why this is. It works in SITL, maybe it is just a robustness issue.
• No sure how optimized the 9P2000 server I'm using is, its possible this its not just a AP issue.
• Using lua for the benchmark means were never going to get the top speeds that compare to what we might see with a native benchmark. Hopefully lua is not the limiting factor here.

I think the results are positive, SD similar speeds for write between 1024 and 4096.

[IamPete1]

I have fixed up the higher block size read/write. It now splits long writes into multiple commands. As before we see read and write speeds the same. Speed increases linearly with block size until you have to add another command. This is why 512 and 1024 block size are similar, the with a 1024 buffer size the headers take up some space so 1024 bytes of data have to be sent in two messages. So we send the same number of messages total as we do for the 512 block size.

Currently the splits are all sent sequentially, the next speedup would probably be to send them in parallel. Or increase the buffer size.....

[IamPete1]

Some messing about with buffers gets the write speeds on par with the SD card.

The read/write discrepancy might mean were dropping some messages, I need to look into it some more.