Feat: store/retrieve enrollment expiry in session

[thekaveman]

Closes #1981

New session helpers:

• enrollment_expiry gets the current user's expiration as a datetime, or None
• enrollment_reenrollment gets the current user's reenrollment as a datetime, or None
• update accepts enrollment_expiry as a datetime

New context_processor:

• Adds expiration, reenrollment, and supports_expiration under the enrollment key

{ 
  "enrollment": {
    "expiration": datetime | None,
    "reenrollment": datetime | None, 
    "supports_expiration": bool
  }
}

Also removed most of the noisy logging from session.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
benefits/core
context_processors.py
session.py
Project Total

This report was generated by python-coverage-comment-action

[angela-tran]

This looks great! I thought through the implications of having the session calculate the reenrollment date every time (as opposed to having the view set it on the session), and that seems fine to me.

[angela-tran]

I thought through the implications of having the session calculate the reenrollment date every time (as opposed to having the view set it on the session), and that seems fine to me.

I think it does mean that there's no need for any expiration.calculate_reenrollment_date function

[thekaveman]

I thought through the implications of having the session calculate the reenrollment date every time (as opposed to having the view set it on the session), and that seems fine to me.

I think it does mean that there's no need for any expiration.calculate_reenrollment_date function

Hmm good point.

I think for the first thought, it seems OK for the reenrollment date to be recalculated each time (regardless of where) since it is a fixed offset from the known/stored expiration date.

For the second thought (where to do this calculation) -- I'm open. My thinking was it made sense to put it here since the session will be the "source of truth" for the expiration date for the rest of the app, so it could also be the "source of truth" for the reenrollment date. It does sort of abuse the session and put business logic there, rather than just storing data... so I'm open to moving this out.

[angela-tran]

My thinking was it made sense to put it here since the session will be the "source of truth" for the expiration date for the rest of the app, so it could also be the "source of truth" for the reenrollment date.

Yeah, I think ultimately we need the reenrollment date in the context processor and therefore need it on the session. As for if the the calculation is done directly inside the session module or is in a separate module that is called by session, I don't think it makes a big difference in this PR.

Maybe in my PR I can move the calculation into benefits.enrollment.expiration?

[thekaveman]

My thinking was it made sense to put it here since the session will be the "source of truth" for the expiration date for the rest of the app, so it could also be the "source of truth" for the reenrollment date.

Yeah, I think ultimately we need the reenrollment date in the context processor and therefore need it on the session. As for if the the calculation is done directly inside the session module or is in a separate module that is called by session, I don't think it makes a big difference in this PR.

Maybe in my PR I can move the calculation into benefits.enrollment.expiration?

Hmmm but the problem is we can't/don't want benefits.core.session to depend on/import benefits.enrollment.expiration, the imports typically go the other way (and we might run into a circular import issue if we try to go this way).

[angela-tran]

Hmmm but the problem is we can't/don't want benefits.core.session to depend on/import benefits.enrollment.expiration, the imports typically go the other way (and we might run into a circular import issue if we try to go this way).

Oh I see. I'm leaning now towards just keeping it in benefits.core.session. The business logic is not complicated, and the value is derived from something that was set on the session.