Right now, shared objects (eg: shared templates, shared vpns) are hidden to non superusers.

The objects are hidden also when selecting related objects, eg: a non superuser cannot select a shared VPN server when creating a VPN-client template.

It would be great to allow non-superusers to see these items in readonly mode and select them when creating objects which have relations to other objects which are shared.

This change should be done for admin and API views.

Prevent non-superusers from creating shared objects

Due to the fact that it will be possible to select the "Shared systemwide" option, this may open the possibility for unauthorized users to create shared objects as it seemed to be the case with https://github.com/openwisp/openwisp-firmware-upgrader/pull/297/files#r2041173844.

We need to add a mechanism in the admin classes and in the serializer classes that prevents this.

I wonder if during validation we can check whether a related model can be shared and in that case we can ensure that only superusers can chose shared relations.

Reusable classes

We should strive as much as possible to create base classes and utilities for the admin, REST API and tests to reuse across all the django modules.

DRF 3.16

I found that after upgrading DRF to 3.16 endpoints in openwisp-controller using the CaListSerializer were failing with the following error:

assert not (required and default is not empty), NOT_REQUIRED_DEFAULT
AssertionError: May not set both `required` and `default`

It happens because of this line:
https://github.com/openwisp/openwisp-controller/blob/1745a0a04f43708d7b402a292d208ca20a010376/openwisp_controller/pki/api/serializers.py#L81

If I remove that line, the tests pass, but I am then able to create a shared Ca with a non superuser org admin/manager user account, which is not what we want and is worrying: we need tests to protect us from these possible security holes.
I also verified that upgrading to DRF 3.16 allows to create objects by omitting the "organization" field, hence allowing non superusers to omit this field and create shared objects, opening security holes.

I think it may be necessary to work on these changes while also upgrading DRF to 3.16 and bind the version, otherwise we may have to work on this twice.