[lib] Remove setCookieOnRequest

Summary:
[ENG-4747](https://linear.app/comm/issue/ENG-4747)
Depends on D9290

After D9288 both web and native had this config set to true so we can remove it and simplify the code.

Test Plan: `yarn flow-all`

Reviewers: inka, kamil, atul, ashoat

Reviewed By: atul, ashoat

Subscribers: ashoat, tomek, wyilio

Differential Revision: https://phab.comm.dev/D9502

lib/utils/call-server-endpoint.js

@@ -75,13 +75,6 @@ type RequestData = {
   platformDetails?: PlatformDetails,
 };
 
-// If cookie is undefined, then we will defer to the underlying environment to
-// handle cookies, and we won't worry about them. We do this on the web since
-// our cookies are httponly to protect against XSS attacks. On the other hand,
-// on native we want to keep track of the cookies since we don't trust the
-// underlying implementations and prefer for things to be explicit, and XSS
-// isn't a thing on native. Note that for native, cookie might be null
-// (indicating we don't have one), and we will then set an empty Cookie header.
 async function callServerEndpoint(
   cookie: ?string,
   setNewSession: (sessionChange: ClientSessionChange, error: ?string) => void,
@@ -146,14 +139,8 @@ async function callServerEndpoint(
     json = await uploadBlobCallback(url, cookie, sessionID, input, options);
   } else {
     const mergedData: RequestData = { input };
-    if (getConfig().setCookieOnRequest) {
-      // We make sure that if setCookieOnRequest is true, we never set cookie to
-      // undefined. null has a special meaning here: we don't currently have a
-      // cookie, and we want the server to specify the new cookie it will
-      // generate in the response body rather than the response header. See
-      // session-types.js for more details on why we specify cookies in the body
-      mergedData.cookie = cookie ? cookie : null;
-    }
+    mergedData.cookie = cookie ? cookie : null;
+
     if (getConfig().setSessionIDOnRequest) {
       // We make sure that if setSessionIDOnRequest is true, we never set
       // sessionID to undefined. null has a special meaning here: we cannot

lib/utils/config.js

@@ -14,7 +14,6 @@ export type Config = {
     logInActionSource: LogInActionSource,
     getInitialNotificationsEncryptedMessage?: () => Promise<string>,
   ) => Promise<void>,
-  +setCookieOnRequest: boolean,
   +setSessionIDOnRequest: boolean,
   +calendarRangeInactivityLimit: ?number,
   +platformDetails: PlatformDetails,

lib/utils/upload-blob.js

@@ -17,14 +17,8 @@ function uploadBlob(
   options?: ?CallServerEndpointOptions,
 ): Promise<CallServerEndpointResponse> {
   const formData = new FormData();
-  if (getConfig().setCookieOnRequest) {
-    // We make sure that if setCookieOnRequest is true, we never set cookie to
-    // undefined. null has a special meaning here: we don't currently have a
-    // cookie, and we want the server to specify the new cookie it will generate
-    // in the response body rather than the response header. See
-    // session-types.js for more details on why we specify cookies in the body.
-    formData.append('cookie', cookie ? cookie : '');
-  }
+  formData.append('cookie', cookie ? cookie : '');
+
   if (getConfig().setSessionIDOnRequest) {
     // We make sure that if setSessionIDOnRequest is true, we never set
     // sessionID to undefined. null has a special meaning here: we cannot

native/config.js

@@ -9,7 +9,6 @@ import { persistConfig, codeVersion } from './redux/persist.js';
 
 registerConfig({
   resolveInvalidatedCookie,
-  setCookieOnRequest: true,
   setSessionIDOnRequest: false,
   calendarRangeInactivityLimit: 15 * 60 * 1000,
   platformDetails: {

web/app.react.js

@@ -84,7 +84,6 @@ registerConfig({
   // We can't securely cache credentials on web, so we have no way to recover
   // from a cookie invalidation
   resolveInvalidatedCookie: null,
-  setCookieOnRequest: true,
   setSessionIDOnRequest: true,
   // Never reset the calendar range
   calendarRangeInactivityLimit: null,