UI: fix token expiry banner for batch tokens

[andaley]

Description

Ensures the "token expired" banner displays in the UI when logged in via a batch token, regardless of whether that token was generated via an auth method or via vault token create directly.

Previously the banner would not display for users logged in with a batch token that was generated by an auth method.

Screenshot

Batch tokens show token expiry banner

Service tokens show token expiring soon banner

Service tokens show token expiry banner

TODO only if you're a HashiCorp employee

• Labels: If this PR is the CE portion of an ENT change, and that ENT change is
  getting backported to N-2, use the new style backport/ent/x.x.x+ent labels
  instead of the old style backport/x.x.x labels.
• Labels: If this PR is a CE only change, it can only be backported to N, so use
  the normal backport/x.x.x label (there should be only 1).
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  of a public function, even if that change is in a CE file, double check that
  applying the patch for this PR to the ENT repo and running tests doesn't
  break any tests. Sometimes ENT only tests rely on public functions in CE
  files.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[andaley]

i believe this is the root of the problem. depending on what login method the user is using (token, userpass, LDAP etc), we hit a different API endpoint, and those apis have a different response shape. note the difference between the various responses:

1. a GET /auth/token/lookup-self (using a batch token created via vault token create -type=batch -policy=test -ttl=20m) responds with type: "batch" and expiry_time properties. API docs confirm this.
2. a POST to /auth/userpass/login (using a username and password with a batch token) responds with a property called token_type: "batch" and lease_duration but doesn't include an explicit expiry_time. API docs confirm this, too

	endpoint	response
/auth/token/lookup-self
/auth/userpass/login

the frontend code on line 308 above suggests to me that we expect the backend responses to be the same regardless of whether the batch token was created via an auth method or via vault token create -type=batch -policy=test.

[github-actions]

CI Results:
All Go tests succeeded! ✅

[andaley]

the this.calculateExpiration function is already set up to handle batch tokens returned by /auth/[backend]/login methods since those APIs return a lease_duration, which is accounted for on line 220 above.

as a result, i didn't see a reason why we wouldn't couldn't call calculateExpiration regardless of whether or not resp.renewable or not.

so you'll notice i modified this.calculateExpiration to handle the case where resp.type === 'batch' (which happens when logging in via a token directly). this way calculateExpiration is used universally, regardless of the authentication method (token/userpass/ldap, batch token, service token etc).

[hashishaw]

This looks like a great approach! I think we just need to do some manual testing for various login expiry flows (unfortunately those are difficult to test automatically)

[github-actions]

Build Results:
All builds succeeded! ✅

[hashishaw]

Elegant solution and beautiful test coverage! ✨ thank you!