rootdir: init.rc: update max TCP window sizes for mobile networks

GRPS: RTT=600ms, max tput=80kbps (class 12 GMSK 4+1)
EDGE: RTT=300ms, max tput=236kbps (class 12 8PSK)
UMTS: RTT=200ms, max tput=384kbps (R99)
HSDPA: RTT=75ms, max tput=14Mbps (cat 10)
HSUPA: RTT=50ms, max tput=14Mbps
HSPA: RTT=50ms, max tput=14Mbps
HSPA+: RTT=50ms, max tput=42Mbps (cat 20)
LTE: RTT=20ms, max tput=100Mbps (class 3)

bug 67569

Change-Id: I9d62359bbd11dc68e3649a7ea2295d0d4e25e3f2
Signed-off-by: Narayan Reddy <narayanr@nvidia.com>
Signed-off-by: Steve Lin <stlin@nvidia.com>

Conflicts:
	rootdir/init.rc

Conflicts:
	rootdir/init.rc
Handle errno properly to avoid corrupt str_parms

A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.

str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.

But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!

It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.

Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f