Many TCP CC mechanisms rely on newreno as fallback, or
to handle common behavior. Originally, cc_newreno did
not have any cc-specific data, but that changed with
D11616.

Most other CC algos do use local data, and when calling
newreno_cong_signal from there, the latter misinterprets
the data as its own struct, leading to incorrect behavior.

Doing an additional check only in newreno for now, as
no other CC interdependencies seem to exist.

Using CC DCTCP on a session where ECN is not negotiated
would erroneously trigger session-specific beta values
on loss, leading to unexpected TCP behavior.

Reported by: chengc_netapp.com