drop potentially unused extractFcAttachments?

[tomholub]

    // tslint:disable-next-line:no-unsafe-any
    return decodeURIComponent(Array.prototype.map.call(base64decode(str.replace(/-/g, '+').replace(/_/g, '/')), (c: string) => {
      return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
    }).join(''));

Originally posted by @IvanPizhenko in FlowCrypt/flowcrypt-android#1057 (comment)

[tomholub]

This is used in base64urlUtfDecode (with opposite base64urlUtfEncode), which are in turn used in htmlAttrDecode and htmlAttrEncode.

htmlAttrEncode is used here in getPwdMsgSendableBodyWithOnlineReplyMsgToken:

      const infoDiv = Ui.e('div', {
        'style': 'display: none;',
        'class': 'cryptup_reply',
        'cryptup-data': Str.htmlAttrEncode({
          sender: newMsgData.from,
          recipient: Value.arr.withoutVal(Value.arr.withoutVal(recipients, newMsgData.from), this.acctEmail),
          subject: newMsgData.subject,
          token: response.token,
        })
      });

htmlAttrDecode is used in:

• extractFcAttachments:
  • decideDecryptedContentFormattingAndRender used in various places + in mobile-core endpoints
  • fmtDecryptedAsSanitizedHtmlBlocks again various places
• extractFcReplyToken:
  • fmtDecryptedAsSanitizedHtmlBlocks (3x)

[tomholub]

It seems that attachments are already encoded differently - with pgp/mime (need to cross-check flowcrypt-web reply repo to be sure), so we could potentially at least drop extractFcAttachments.

However, for the reply tokens, I'll have to think about this some more. It's also related to upcoming planned feature to self-host web portal on FES.