pmpro_next_payment() not accounting for expiring accounts

[eighty20results]

If using pmpro_next_payment() without filtering the returned date explicitly for this case, it ignores the expiration date (if set). We typically set the enddate for cases where the admin wants the membership to expire at the end of the payment cycle when cancelling, not when the operation is done.

Does it make sense to have pmpro_next_payment() include a check for enddate being set for the user, before attempting to use the period & previous order to calculate what will likely be an incorrect "next billing date" (there shouldn't be one).

I can add a check if this is an approach you think would be appropriate.

I think this makes sense. It should return false if the next payment will never come. At the same time, the subscription will still exist on the gateway, which is a little odd. I wonder if we should proactively cancel the subscription at the gateway as well. In any case, I think it makes sense for the next payment function to also check the expiration date.

[dparker1005]

In addition to expiring memberships, this function also doesn't check for levels with billing limits. We could probably go about checking this by counting the number of previous orders made with the same subscription id and comparing that to the billing limit for the level.