It would not be EAGAIN/EBUSY since you can't do it again and expect it to succeed. I think
EINVAL is ok here.

Ok turns out skyzaller has found yet another crash having to do with TFO for all three stacks. Lets update
the patch to fix that too.

Has discussed on the transport call, I will be updating these to have a uint64_t and a nano-second basis for the values (including t_starttime I think since this
is what you compare these against) :)

I don't think that holding just the delta is what you really want. You want to be able
to tell when the first byte came in and the first byte went out. The delta only gives
one a partial view of what happened. And we are not living in 1984 where 64k of
memory is a lot. Four bytes to get more detailed information is I think worth it.

Note that we don't want to commit these for a while since skyzaller uses these addresses but it
is something we should do.

Hmm I somehow got the wrong patch here.

Yeah the spelling error check is rather dumb :)

We should not ever do GP measurements until we are established

One little other niggle that I noticed, we should not do a goto again if the SYN bit is set ...

And even yet another issue thanks to skyzaller in bbr.. the rc_lost when doing TCP-FO was incorrect in rxt timers.

Let's also fix the accounting panic that skyzaller is finding here too. When we are in a front
state and have a SYN outstanding that should count in the ctf_outstanding size. Also if
we have sent a FIN same thing.

gets rid of some emacs trailing ws

Follow Michaels suggestion and go 2016 - 2020 in the copyright instead of 2016 - 20

Even though there are no plans to add ECN to BBRv1, lets go ahead
and add back the uint8_t iptos value since you never know we might
circle back and do this plus we also want to remain somewhat consistent
between BBR and Rack

I would suggest leaving the iptos changes in. It does not
harm in BBR and someday we will be doing BBRv2 and in
that we will do ECN.. so best to leave it in place I think.

Lets go ahead and add the new function to return that we don't do PRUS_OOB as long as we are in fixing things.

Update to fix inadvertent overwrite of error and the name of the option function change per Michael's comment

Now that D24575 is in lets take it a step further and provide the hooks so
we can ask a transport (optionally) if they support various PRU_XXX flags.
If they don't provide a function then they "support all" PRU_XXX flags.

Now that I know MSG_OOB is out of the picture make the appropriate update.

Address all of Michael's first set of comments.

Address all of Michael's comments

Update comments and name of the mss function per the comments in the review.

Address Hans comments, also fix the issue I had
when I back things out (the net epoch macro should have
been in the source).. also add just a few more comments and
fix a spelling error in one.

Commited