Digest auth new

[pratt4]

This is build on top of #2089

and still some changes are required around new testcases and failing testcases

closes #2068

[hyperxpro]

I'll have a look on the weekend. :)

[hyperxpro]

I think only the auth-int implementation is not complete.

[pratt4]

Thanks @hyperxpro for pointing that out! I’ve started implementing auth-int
I will push phase 1 in 1-2 days

[pratt4]

things to do

• Support unlimited size request bodies using streaming: implement DigestingBodyGenerator that hashes while streaming (no upfront buffer), lifting the 10 MB limit
• Adding a repeatability contract (e.g... isRepeatable()) to BodyGenerator so client auto-selects buffering or streaming modes
• Optimization of FileBodyGenerator hashing by using zero-copy techniques (FileChannel + ByteBuffer or mmmap slices).
• seamless auth-int support for ReactiveStreams and multipart body generators, preserving async back-pressure.
• Negotiation of strongest hash algorithm automatically when server advertises multiple options (SHA-512-256 first, then SHA-256, then MD5).
• Implementation of the RFC 7616 userhash=true parameter and handle UTF-8 encoded usernames properly.
• Performance improvements on hex-encoding method with lookup-table-based implementation and consider mmap-based hashing.
• Integration tests

[pratt4]

@hyperxpro i have fews questions it would be helpfull if you answer them

1)in Proxy auth is auth-int relevant? because as far as i know proxies happen before getting body
2) currently i dont think the code increments nonce infact it uses DEFAULT_NC=00000001
that means every request that uses Digest today sends nc="00000001". Most servers tolerate that because they don’t enforce nonce-count, but a strict implementation (especially when it also requires auth-int) will expect the counter to rise.
shall we increment it or it is kept default for some reason?

Thanks!

[pratt4]

need to optimize this