Better handle XSRF token expiration when editing

Scenario:

• You start editing a page, and the server gets restarted. You have a persistent auth cookie ("remember me box checked on login") so your periodical heartbeat keeps working, but your XSRF token (tied to the session ID) has expired.
• If you are editing the page and hit "preview", the REST resource will respond with 403 (it does the anti forgery check). Also the periodical "save draft" will fail for the same reason so you get stuck in a situation where the only way out is try saving the page (the action will fail but a new xsrf token will be issued), which sucks.

How to reproduce it easily:

• Create a blog post or page
• Go to Chrome tools and change the xsrf token value by editing manually all the

  <meta name="ajs-atl-token" content="49a13104891a700a54406dfdf3437cb4275dc167">
  <meta id="atlassian-token" name="atlassian-token" content="49a13104891a700a54406dfdf3437cb4275dc167">
  <input type="hidden" name="atl_token" value="49a13104891a700a54406dfdf3437cb4275dc167">
  

  (not sure why we have so many different meta tags containing the xsrf, this ticket may a good opportunity to find out)

• Now hit preview and you will get something similar to the screenshot attached.

Potential fixes/improvements:

• Better notifications. We can check the status code of the response error. If it is 403, we can tell the user what's going on.
• Or better, we can reissue a new XSRF token from the server, and resubmit. Or get a new XSRF and ask the user to resubmit.
• As mentioned above, this needs to be addressed in both preview and save draft.
• A similar solution can be applied to fix CONFDEV-24392 (XSRF token expiration when hitting save)