tcp: Initial ktest for HPTS

[tuexen]

Summary

This patch was developed by Nick Banks.

[rrs]

Testing is a good thing so I think this is well worth having. I will say on the rumor of name changes inside tcp_hpts due to the idea of possibly supporting
more than just TCP. I am unsupportive of this UNTIL we have tcp_hpts being able to handle multiple protocols. When I originally wrote hpts (called pacing not hpts.. Robert
renamed it hpts) I did envision expanding it to include not just TCP but SCTP and maybe even UDP. But the fundamental problem I hit was the fact that choosing where
to dice the thing such that you would have a common call point into the protocol was not a cut and dried thing. For TCP it was easy since there was a clear demark between
the initial input of the packet and the actual segment processing, which I used when I broke out the multiple stacks idea. However for SCTP and UDP no such clear
basis exists that is common with TCP..... or even between SCTP and UDP... so I back down and decided to implement it has a TCP thing. Now if someone comes up
with a clean and elegant way to call into to TCP/SCTP and UDP then name changes would be appropriate within the code.. without that elegant set of proposed
changes name changes I am STRONGLY against and will object to since they are just irrelevant until HTPS can support multiple protocols... so in summary

1. HPTS needs a clean way to do multiple protocols *first*
2. Name changes afterwards

Not the other way around :)

[nickbanks_netflix.com]

In D52979#1210419, @rrs wrote:

Testing is a good thing so I think this is well worth having. I will say on the rumor of name changes inside tcp_hpts due to the idea of possibly supporting
more than just TCP. I am unsupportive of this UNTIL we have tcp_hpts being able to handle multiple protocols. When I originally wrote hpts (called pacing not hpts.. Robert
renamed it hpts) I did envision expanding it to include not just TCP but SCTP and maybe even UDP. But the fundamental problem I hit was the fact that choosing where
to dice the thing such that you would have a common call point into the protocol was not a cut and dried thing. For TCP it was easy since there was a clear demark between
the initial input of the packet and the actual segment processing, which I used when I broke out the multiple stacks idea. However for SCTP and UDP no such clear
basis exists that is common with TCP..... or even between SCTP and UDP... so I back down and decided to implement it has a TCP thing. Now if someone comes up
with a clean and elegant way to call into to TCP/SCTP and UDP then name changes would be appropriate within the code.. without that elegant set of proposed
changes name changes I am STRONGLY against and will object to since they are just irrelevant until HTPS can support multiple protocols... so in summary

1. HPTS needs a clean way to do multiple protocols *first*
2. Name changes afterwards

Not the other way around :)

Thanks @rrs for the context and feedback. I think that's completely reasonable. My goal was to focus on the refactoring and *eventually* get around to a name change. It's not the priority.