Separated members token mw from members session mw

- The existing createSessionFromToken was actually doing two things behind the scenes
   1. Handling the ?token from the magic link and creating an actual session (mounted globally, which is not necessary)
   2. Loading an existing session so that a member is logged in to the frontent
- IMO 1. is part of members, and doesn't need to be global
- IMO 2. is part of the frontend. It does need to be global but should NOT be hidden away behind the token middleware, as it wasn't clear what this was doing

core/server/services/members/middleware.js

@@ -93,11 +93,14 @@ const decorateResponse = function (req, res, next) {
     next();
 };
 
-// @TODO only loads this stuff if members is enabled
+// @TODO only load this stuff if members is enabled
 // Set req.member & res.locals.member if a cookie is set
 module.exports = {
-    createSessionFromToken: [
+    memberSession: [
         getMemberDataFromSession,
+        decorateResponse
+    ],
+    createSessionFromMagicLink: [
         exchangeTokenForSession,
         decorateResponse
     ],

core/server/web/site/app.js

@@ -137,8 +137,11 @@ module.exports = function setupSiteApp(options = {}) {
     siteApp.delete('/members/ssr', shared.middlewares.labs.members, membersMiddleware.deleteSession);
     siteApp.post('/members/webhooks/stripe', shared.middlewares.labs.members, membersMiddleware.stripeWebhooks);
 
-    // Currently global handling for signing in with ?token=
-    siteApp.use(membersMiddleware.createSessionFromToken);
+    // Currently global handling for signing in with ?token= magiclinks
+    siteApp.use(membersMiddleware.createSessionFromMagicLink);
+
+    // Global handling for member session, ensures a member is logged in to the frontend
+    siteApp.use(membersMiddleware.memberSession);
 
     // Theme middleware
     // This should happen AFTER any shared assets are served, as it only changes things to do with templates