Recalculate a session from its meter values: the existing charging periods are removed and rebuilt, the session
metrics are recomputed, the validation rules are re-run and the billing status is updated from the result. The action
runs as the token owner, who is recorded on the session edit log and on the action audit record.

Requires the Sessions.resume-billing permission - a token whose admin does not hold it is rejected with 403, and so
is a request for a session that belongs to another operator. An unknown session ID is rejected with 404.

Preconditions, with the response code each failure produces:

• billingStatus is not completed - otherwise 409
• Billing for the session is not owned by the upstream roaming partner - otherwise 409
• status is finished, or pending or active for a session that is already underway at the charge point -
  otherwise 409. Not every pending or active session qualifies: pending also covers a session that has not
  been sent to the charge point yet, and active also covers a session that has stopped and is waiting for the
  cable to be unlocked - both are rejected.
• The StartTransaction message is still present in the session's communication logs - otherwise 409
• No recalculation is running for the session and the session is not locked for billing processing - otherwise 423
• reason is at most 1000 characters - otherwise 422

202 means accepted, not recalculated. The recalculation is queued and runs asynchronously, so a successful
response only states that the preconditions held and the work was scheduled; the recalculation itself can still fail
afterwards, in which case the session is restored to its previous state. Two outcome channels report the final
result: subscribe to the SessionUpdateNotification callback, or poll the session resource. billingStatus passes
through pending while the session is being recalculated before settling on its final value; for a session that is
still underway it stays pending and the validation rules are not run until the session stops.

Three risks are inherent to the recalculation and are not prevented by the platform:

• The recalculation replays the session's communication logs. Those logs are rotated, so a session old enough to
  have lost them can no longer be recalculated even though every other precondition holds.
• The recalculation prices the session against the tariff captured when the session started, not the tariff in
  effect now. Editing or deleting the tariff after the session ran does not change the recalculated amounts.
• Two callers can each receive 202 for the same session. Only one recalculation takes effect; the other is skipped
  when it runs - because another recalculation holds the per-session lock or billing has already completed - and is
  recorded as a failed action audit record.