fix: broker and proxy must not reject client offers with no ICE candidates

Hey! I suspect that !141 (merged) was a mistake... It was implemented to close #40231 (closed).

The reason is because apparently a connection can still be established even without one party having sent its candidates. And for this the reason is peer reflexive candidates. If the Snowflake proxy has a dedicated IP, the client can connect to it directly.

Just to remind, the client implementation currently removes all local network candidates, so if it's behind NAT, it can only send server-reflexive ones.

As mentioned in #40231 (comment 2890900), this can happen when STUN is blocked for the client.

I have tested it with this little page.

1. Wait for the offer to generate.

2. Click "copy"

3. Paste the offer in a text editor, and remove all server reflexive (STUN) candidates and mutilate the mDNS host candidate (or simply replace with a fake, made-up one) so it's not gonna work.

   (you could also open dev tools and comment out the line with iceCandidates for new RTCPeerConnection(), but don't forget to mutilate the mDNS candidate for extra assurance)

   At least one candidate must exist because, as this issue says, currently the broker rejects offers with no candidates.

4. Request a proxy by sending the offer to the broker, e.g. by sending it to snowflake.rendezvous.chatbot@gmail.com (see https://github.com/WofWca/snowflake-rendezvous-email-chatbot)

5. Paste the answer on the test page from step 1 and click "Submit"

Surprisingly, connection established! chrome://webrtc-internals/ says that the local candidate is peer reflexive, even though we never sent any to the proxy!

I do not know if this will work with our current implementation of the client though (as mentioned in #40231 (comment 2890900)), but at least if it works in Chromium, we should make it work in Snowflake! (again, because STUN could be blocked for some clients)

Additionally, the assertion implemented in !141 (merged) doesn't really protect from DOS, because the DOSer could just make up ICE candidates, or even use real ones - it shouldn't cost them much. But perhaps it still makes sense to reject the offer if the client's NAT type is "unrestricted", but again, this can be faked...