Precompute ephemeral keypairs for ntor

[nickm]

In the ntor handshake, on the server side, we need to generate a new y,Y pair for every handshake. But there's no reason this needs to happen on demand; instead, it could be lovely to do batches of them ahead of time, so that we can respond to requests faster. This wouldn't lower our CPU requirements when we were under load, but it might help us with circuit creation latency under less-than-horrible loads.

Before we go ahead and do this, it might be clever to verify that there are in fact times when cpuworkers are idle on busy servers.

[nickm]

These may be worth looking at for 0.2.7.

[nickm]

Marking some tickets as triaged-in for 0.2.7 based on early triage

[nickm]

Bulk-replace SponsorU keyword with SponsorU field.

[nickm]

I'm not sure about precomputation in general, but it's pretty easy to do for the create cell case. I have a not-quite-complete branch in pregen_curve25519 that might make it look worthwhile.

Why is this branch incomplete?

• It needs to start calling cpu_init() unconditionally, like #13737 does.
• It may break some tests.
• Linking isn't quite right.

[nickm]

It is impossible that we will fix all 188 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "needs_revision" tickets, looking for things to move to 0.2.9.

Note that if the requested revisions happen in advance of the 0.2.8 freeze, they can get considered for 0.2.8.

[nickm]

setting owner.

[nickm]

Deferring; I don't see a huge benefit for this right now.

[teor]

Milestone renamed

[nickm]

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

[nickm]

Remove an old triaging keyword.

[nickm]

None of these revisions are in my near-term plans.