Improve RichTextCodec decoding performance

[987Nabil]

Error messages are the same per instance of CharIn. So we compute them
only once.

[codecov-commenter]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (bc6c29b) 64.94% compared to head (36626ec) 64.90%.

Files	Patch %	Lines
.../src/main/scala/zio/http/codec/RichTextCodec.scala	77.77%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2512      +/-   ##
==========================================
- Coverage   64.94%   64.90%   -0.04%     
==========================================
  Files         137      137              
  Lines        7243     7247       +4     
  Branches     1248     1264      +16     
==========================================
  Hits         4704     4704              
- Misses       2539     2543       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kyri-petrou]

@987Nabil just leaving this comment here for visibility.

Thanks for the fix but just want to raise a concern with this approach. It "fixes" the latency the issue in situations that an instance of the RichTextCodec is reused, but my worry is that at some point in a few months / years will use RichTextCodec.filter(_ => true) in a method and the same issue will arise again

I'm sure you already thought of different approaches, but does the error message needs to contain every single character in the BitSet? Perhaps it can be limited to the first 5 or 10 or even 50? If I'm understanding the code correctly, it currently contains all 65535 chars, and I'm not too sure whether that's really useful.

[jdegoes]

You can do one better by removing lazy, and adding:

private[codec] val leftErrorMessage = Left(errorMessage)

Then using leftErrorMessage below.

[987Nabil]

@kyri-petrou I see your point. I must say, the need for going with RichTextCodec.filter(_ => true) is, that one can not provide error messages. I think this could maybe already be better handled right now. I could also choose some max for adding the char to the error message.

[jdegoes]

We discussed using describe to provide compact, nice descriptions of the codec on failure.

[jdegoes]

This is rendering poorly, perhaps because describe returns Doc, that should first be properly converted into a string.

[987Nabil]

The problem is actually the | operator, that chains error messages this way explicitly.