Bug 1640745 - fix NewChannelId so that ids fit into safe JS integer range r=necko-reviewers,valentin

On Linux PID_MAX_LIMIT is 2^22. By default pid_max was set to 2^15, but
systemd since version 243 sets it to 2^22.
nsHttpHandler::NewChannelId uses PID shifted by 32 bits to generate
channelId, and that results in values greater than 2^53.
Such values are fine for uint64_t, but when we pass channelId to
devtools it gets converted to JavaScript floats, and values greater
than 2^53 get errors in lower two bits. This in turn leads to much
sorrow, like request id collisions or "no headers for this request".

This patch shifts the PID by one bit less, resulting in channelIds
that always fit into safe JavaScript integer range for all PIDs.

Differential Revision: https://phabricator.services.mozilla.com/D85990

netwerk/protocol/http/nsHttpHandler.cpp

@@ -2743,7 +2743,11 @@ void nsHttpHandler::ShutdownConnectionManager() {
 
 nsresult nsHttpHandler::NewChannelId(uint64_t& channelId) {
   channelId =
-      ((static_cast<uint64_t>(mProcessId) << 32) & 0xFFFFFFFF00000000LL) |
+      // channelId is sometimes passed to JavaScript code (e.g. devtools),
+      // and since on Linux PID_MAX_LIMIT is 2^22 we cannot
+      // shift PID more than 31 bits left. Otherwise resulting values
+      // will be exceed safe JavaScript integer range.
+      ((static_cast<uint64_t>(mProcessId) << 31) & 0xFFFFFFFF80000000LL) |
       mNextChannelId++;
   return NS_OK;
 }