API for name completion data.

[isoos]

• /api/dart2-package-name-completion-data #4302
• Tested search responses on staging: 400-600 ms on the search instance to serve the content, a 200-500 ms more on the frontend instance to parse, transform and cache it. If we were to use a binary protocol for search, this could be reduced by about 50-150 ms.
• The uncompressed size is about 280k, the compressed is about 80k with the default gzip settings.
• Caching the gzipped content for 8 hours seems to be a good balance.
• Clients that do not accept gzip encoding are rejected with HTTP 406.
• Added to integration test (also checks on post-deployment) - as long as retry is a popular package, it won't fail :).

[jonasfj]

200-500 ms more on the frontend instance to parse

Is that CPU time on the main thread of the frontend instance?

That'll make a lot of other requests much slower.. Should we consider making a ?compact=1 mode for search backend, where it only returns package names?

Maybe we should forbid limit > 100 unless compact=1 on the search backend?

[isoos]

Is that CPU time on the main thread of the frontend instance?

It was local benchmark.

Should we consider making a ?compact=1 mode for search backend, where it only returns package names?

Good point, however, the result format would be somewhat different: instead of "packages": [{"package": "<pkg>"}, {...}, ...] we would have `"packageNames": ["", "", ]). I'd add that in a separate PR.

Maybe we should forbid limit > 100 unless compact=1 on the search backend?

Not sure if this is necessary...