develop strategy for close-sourcing sensitive server components

[tayloraswift]

for background, we know that somebody spent a lot of effort trying to take the Swiftinit site offline in Q4 2023, and that these attempts have continued sporadically into Q1 2024. the nature of the attacks and the endpoints they hit suggest (to me at least) that the attacker had read the source code for the server and had at least some knowledge of how the documentation service works and how to disrupt it.

we should not rely on security through obscurity, and as a project ostensibly motivated by the public interest, it would be ideal if we could continue practicing open security. however, this has proved unworkable in practice, as it slows us down considerably and prevents us from prototyping and shipping new features without extensive security auditing, as we must assume that hostile entities are watching the project and can notice new, insufficiently-secured endpoints.

close-sourcing enough of the project to keep the production site safe while still keeping enough of the project open source to provide a meaningful public benefit will require some amount of planning. we should investigate:

• spinning off peripheral components of the repo into standalone libraries in their own right
• refactoring the server into a stripped-down version suitable for local testing, and a secret version to use in production. this means dividing the SwiftinitServer target.

[tayloraswift]

OTOH, the IP and URI parsers are good candidates for standalone libraries

[tayloraswift]

abebe42b7e7c76ecacf0afcd9b8add8203e68d34 separates the plugins and firewall logic from the main server application