Add network developer docs

[Courtney3141]

Mentions #523 in section ### Memory barriers and atomicity section, this will need to be updated when merged.

[omeh-a]

All in all pretty good with some minor grammar things + suggested changes for clarity. I think this could still be condensed a bit further however and I'm not sure that the current structure is ideal for a new reader. E.g. some info like the sdf gen stuff is repeated and I think some headings aren't in the natural order I would want to understand this as a new user. Might be worth reordering some headings to follow more of a top-down instead of bottom-up ordering, since users generally want to start with "How can I use the network for my example" instead of "how does the queueing protocol work"? Alternatively a table of contents with links to headings could be a good solution

[Courtney3141]

All in all pretty good with some minor grammar things + suggested changes for clarity. I think this could still be condensed a bit further however and I'm not sure that the current structure is ideal for a new reader. E.g. some info like the sdf gen stuff is repeated and I think some headings aren't in the natural order I would want to understand this as a new user.

I agree with this, especially the ordering, but for the time being I think it is okay and much better than nothing. I don't have that much time to invest in it further for the moment, but I can come back to it next year (also happy for others to do this as well).

Might be worth reordering some headings to follow more of a top-down instead of bottom-up ordering, since users generally want to start with "How can I use the network for my example" instead of "how does the queueing protocol work"? Alternatively a table of contents with links to headings could be a good solution

Hopefully with the markdown links it should be easy to jump around. There is also an argument that you should force people to read some sections before using the subsystem immediately e.g. like the signalling protocol. In general I like structuring my docs from higher abstraction to lower as well.

Table of contents could work too but I'd like it to be standardised for all sDDF docs.

Thank you. I have fixed up a lot of the minor things and grammar. Hopefully I have added a bit of clarity.

For the moment, if you believe I've fixed everything suggested can we leave the major changes to later and just get this merged as a first start.

[Courtney3141]

#596 can be merged once this is merged (dependent on this PR as it adds/fixes up the docs with it).

[omeh-a]

All in all pretty good with some minor grammar things + suggested changes for clarity. I think this could still be condensed a bit further however and I'm not sure that the current structure is ideal for a new reader. E.g. some info like the sdf gen stuff is repeated and I think some headings aren't in the natural order I would want to understand this as a new user.

I agree with this, especially the ordering, but for the time being I think it is okay and much better than nothing. I don't have that much time to invest in it further for the moment, but I can come back to it next year (also happy for others to do this as well).

Might be worth reordering some headings to follow more of a top-down instead of bottom-up ordering, since users generally want to start with "How can I use the network for my example" instead of "how does the queueing protocol work"? Alternatively a table of contents with links to headings could be a good solution

Hopefully with the markdown links it should be easy to jump around. There is also an argument that you should force people to read some sections before using the subsystem immediately e.g. like the signalling protocol. In general I like structuring my docs from higher abstraction to lower as well.

Table of contents could work too but I'd like it to be standardised for all sDDF docs.

Thank you. I have fixed up a lot of the minor things and grammar. Hopefully I have added a bit of clarity.

For the moment, if you believe I've fixed everything suggested can we leave the major changes to later and just get this merged as a first start.

As discussed in person, definitely fine to leave restructuring etc. for later. Just minor thoughts really :) Will merge.