~singpolyma/sgx-jmp

ref: 045da39f25b74034e7bba44cb5f1db48a935ba84 sgx-jmp/lib d---------
Hotfix: arguments in wrong order
The sugar version prevents the promise from being returned
Merge branch 'finish-btc'

* finish-btc:
  No more legacy session for BTC
  Do not lose WebRegisterManager on retart
No more legacy session for BTC

Set the same key as web register manager, so that on next register jmp.chat the
tel we were using in this flow will be used.   Not needed if they came from web
register, but will still extend expiry in that case and no harm.

Clean up pending tel key on Finish.
Do not lose WebRegisterManager on retart

Store web registrations in redis.  Set an expiry so they don't grow in RAM
forever as they previously would have without a restart.
Customer Visible Plan Info

We moved some of the currently private things to be public, like currency, and
then included things like how much the monthly price is as well.
Handle False Registration

Turns out my dummy-sgx doesn't act the same as production.
Rather than getting a successful registration with no phone, in production I
get false, so I need to handle that.
Customer Info

This should allow us, the admins, to query information about a customer
without having to dive in and run a couple redis queries and some
database queries before getting the full picture of who we're talking
to.

It also allows the users to request some data about themselves. Balance and
phone number are already visible in other places, but their expiry is currently
not, and people have been asking about it.
Remove BigDecimal.new

It turns out in newer versions of Ruby this isn't cool anymore.
The new way is BigDecimal(value), which is dumb, but whatever...
Merge branch 'invite-codes'

* invite-codes:
  Command to list unused invite codes
Command to list unused invite codes

Instructions also provide details about how the program works.
Fix variable reference
It's never been called customer.id
Bring in line with the key from billing_monthly_cronjob
Customer always has a JID
Merge branch 'low-balance-auto-top-up'

* low-balance-auto-top-up:
  Some people have exactly 5 who don't need to be told
  On low balance, top-up or notify
  ExpiringLock helper
On low balance, top-up or notify

On start up, check for users with low balance and NOTIFY about them.  LISTEN for
such notifications and process by either sending a low-balance warning message
or else attempting an auto-top-up as configured.

Using NOTIFY/LISTEN because then we can NOTIFY after any INSERT that leaves the
balance too low (using a trigger).  Doing the sync on start-up in case we missed
a NOTIFY during any downtime.  Using the Redis lock to prevent spamming a
low-balance user in case of many restarts or if they have many small
transactions happen in one day.
ExpiringLock helper

For things we want to do only so often, set up a helper to push expiring keys to
Redis and check for them.
Next