[REF] subscription_oca: split subscription cron responsibilities

[alvaro-domatix]

Problem

cron_subscription_management used to walk every sale.subscription with self.search([]) and decide inside the loop whether to start, invoice or close each record. A single exception aborted the rest of the batch when the failure happened outside the inner try/except (e.g. while starting a subscription), and there was no way to cap the number of records processed in one run.

Solution

Split the entry point into three small dedicated methods with restrictive domains, each guarded by per-record try/except:

• _cron_start_due_subscriptions: activates draft / pre subscriptions whose date_start has passed and issues their first invoice.
• _cron_invoice_due_subscriptions: invoices in-progress subscriptions whose recurring_next_date is due and that actually have lines.
• _cron_close_ended_subscriptions: closes in-progress subscriptions whose end date has passed.

cron_subscription_management keeps working as an entry point that calls all three in order, with a new optional limit argument forwarded to each.

The external behavior of the cron is preserved: existing subscriptions get invoiced, started and closed exactly as before. The only intentional change is that an exception in one record no longer aborts the rest of the batch.

How to test

Run:

odoo-bin -d <db> --init=subscription_oca --stop-after-init
odoo-bin -d <db> -u subscription_oca --test-enable --test-tags=/subscription_oca --stop-after-init

The new tests/test_subscription_cron.py covers:

• The cron does not invoice subscriptions whose recurring_next_date is in the future.
• The cron does not invoice subscriptions without lines.
• A due subscription is invoiced exactly once.
• A UserError raised by one subscription does not stop the batch — the next one is still invoiced.
• Subscriptions whose end date has passed are closed.
• The limit argument caps the number of records processed.

The legacy test_subscription_oca_sub_cron_error test used to assert UserError propagation, which only happened in the previously unguarded start branch; with errors now logged per record across all three methods the cron finishes the batch and the test verifies the call rather than the exception.