add distributed token cache to ExpressTestApp sample

[derisen]

This adds distributed caching support to the ExpressTestApp sample using Redis as persistence client (via node-redis).

The custom cache plugin implements the ICachePlugin. The persistent cache here is a simple key-value store. For each user, there are 2 records:

Key	Value
sessionId	session variable, which contains homeAccountId
homeAccountId	msal's cache blob for that user

The way this works is roughly as follows:

• A custom middleware initializeTokenCachePlugin is used pass the session variable to the custom cache plugin.
• When a user attempts to sign or acquire a token, cache access is triggered:
  * Before cache access, the plugin checks the persistence store for the given sessionId. If a record is found, it grabs the homeAccountId from the session record, and then gets the relevant cache blob using homeAccountId as key. The blob then is deserialized into msal's in-memory cache.
  * After cache access, the plugin checks if the cache has changed (in-memory vs persistence). If so, it serializes the in-memory cache back to persistence store.
• When the user signs-out, the session is destroyed, removing the session data but not token cache for that user.

Couple of observations:

• My intention was to implement this in TypeScript on the wrapper side, as I think this is best abstracted away (ideally, devs should only need supply the persistence client, using whatever persistence solution they like, and the session variable). However, because the initial cachePlugin needs to be re-initialized later on with session variable, and because tokenCache is a private member of ClientApplication, this leads to compile errors.
• During the instantiation of msal client, if cachePlugin field is left as null in the configuration object, it cannot be initialized later on i.e. it effectively sets the msal client to use the in-memory cache only.
• I was expecting acquireTokenSilent to trigger a cache access, (so that beforeCacheAccess/afterCacheAccess runs). This wasn't the case, and I had to call getAccountByHomeId to do the job. This seems off, the dev might be storing the account object in a session or etc. so might not necessarily call this API.

[samuelkubai]

Looks good to me, sample works as expected and a great starting point for distributed caching.

[ghost]

Reminder: The next release is scheduled for next week and this PR appears to be stale :(

If changes have been requested please address feedback.
If this PR is still a work in progress please mark as draft.

[tnorling]

Just a couple nits but otherwise looks good

[tnorling]

Probably should wrap the JSON.parse in a try/catch

[tnorling]

We should validate that kvStore even has any values and then validate that homeAccountId is defined before moving on to the next part

[tnorling]

You can add an .npmrc file with package-lock=false to this directory to prevent package-locks from being generated in the future.

[tnorling]

Let's leave this versioned. You can add scripts to help going back and forth between local and published versions. Some of our other samples demonstrate this.