Optimize parsing headers for pekko-http and akka-http

[kciesielski]

Fixes #3544

CPU samples registered in profiler:
Before:

sttp.tapir.server.pekkohttp.PekkoToResponseBody.parseContentType(String) 3.53%
sttp.tapir.server.pekkohttp.PekkoModel$.parseHeadersOrThrowWithoutContentHeaders(HasHeaders) 2.13%

After:

sttp.tapir.server.pekkohttp.PekkoToResponseBody.parseContentType(String) 0.18%
sttp.tapir.server.pekkohttp.PekkoModel$.parseHeadersOrThrowWithoutContentHeaders(HasHeaders) 0.14%

Throughput in SimpleGet Simulation for 128 users:
Before:

After:

(Yes, the timestamps are OK, I ran the test on the optimized server first :))
Note:
The issue mentions one more hot frame:

sttp.tapir.server.pekkohttp.PekkoServerRequest.acceptsContentTypes() 2.4%

It's a common issue caused by the base ServerRequest.acceptContentTypes calling Accepts.parse from sttp-model, involving some pattern matching. I tried two approaches, without great results:

1. A low-level string-based parser instead of using sttp-model. This lowered CPU samples to ~1.8%, which isn't a great gain, while the code was pretty complex and didn't cover some error corner cases.
2. Switching to Pekko's HttpHeader.parse which is more efficient, then repacking Pekko datatypes to Tapir's. This lowered the load to ~1.9%. Again, doesn't seem worthwhile, the repacking was also pretty complex and error prone, it probably involved unnecessary allocations as well. HttpHeader.parse is not very efficient by itself, because internally it calls

val parser = new HeaderParser(value, settings)

every time. The full power of HeaderParser could be leveraged if the parser was instantiated once and reused within a connection, then passed to new connections once the connection is closed (it has its own internal cache). This is what happens underneath if one uses raw pekko-http.

[adamw]

Maybe we can optimize Accepts.parse somehow then?

[adamw]

But otherwise nice gains! :)

[adamw]

I'm wondering if can get some "wild" media types, e.g. with some parameters, which could fill our cache with junk. We have a list of (currently) 1208 mime types in mimeByExtension.txt, but it has some very weird media types, and parsing them upfront would take significant time. Or maybe we could cache only if contentType.mediaType.params.isEmpty? (well .. maybe except for the charset)

[kciesielski]

I like the idea of storing only values which have empty params (except the charset), this should significantly limit the cases where the cache is not useful after being filled with a lot of types.

[kciesielski]

Maybe we can optimize Accepts.parse somehow then?

I can work some more on this, it's kinda outside of scope of this pekko-specific PR anyway.