[feature] Align user expiration handling with openwisp-users

[pandafy]

Is your feature request related to a problem? Please describe.
User expiration logic (based on an expiration_date field) will be implemented in openwisp-users#499. Currently, openwisp-radius contains its own logic to deactivate expired users created via RadiusBatch, which leads to duplication.

Describe the solution you'd like

• Remove all logic in openwisp-radius that deactivates expired users:
  • Management command: deactivate_expired_users
  • Celery task: deactivate_expired_users in tasks.py
  • The expire() method in the RadiusBatch model
• Retain the expiration_date field in the RADIUS batch user model:
  • This field will only be used to assign the expiration date to generated user accounts
  • It should not be used for enforcing expiration within openwisp-radius
• Ensure that user objects created via RADIUS batch correctly receive the expiration_date from the batch when they are saved.
• When migrating, set the User.expiration_date field for the users
  created as part of RadiusBatch. This will ensure that these users
  will be expired when the celery beat executes the new task from openwisp_users.

Additional context

• The delete_old_radiusbatch_users command should remain as it serves a different purpose (deleting users after 18 months, not just deactivating).
• Users of openwisp-radius will need to remove the deactivate_expired_users and delete_old_radiusbatch_users entries from their CELERY_BEAT_SCHEDULE. This is a breaking change change which should be documented in the changelog.
• These beat schedule entries will be replaced by the new taskadded in openwisp-users.

Blockers

• [feature] Support user expiration with automatic deactivation and notification emails openwisp-users#499