Use primary serializers for nested object relationships

[jeremystretch]

Proposed Changes

Following the work completed in #15235, it is no longer necessary to define separate nested serializers to represent related objects. We can instead pass an arbitrary list of fields to include when rendering the serialized object.

For example, the Site serializer currently utilizes nested serializers to display the region to which a site is assigned:

class SiteSerializer(NetBoxModelSerializer):
    region = NestedRegionSerializer(  # Nested serializer
        required=False,
        allow_null=True
)

Instead, we can use the primary serializers for each of these related models, passing the specific fields we want the nested representation to include:

class SiteSerializer(NetBoxModelSerializer):
    region = RegionSerializer(  # Primary serializer
        requested_fields=['id', 'url', 'display', 'name', 'slug'],
        required=False,
        allow_null=True
    )

Because the desired set of fields typically matches brief_fields set on the related serializer's Meta class, we can reference it directly. (Passing an arbitrary list of fields where necessary is still possible.)

class SiteSerializer(NetBoxModelSerializer):
    region = RegionSerializer(
        requested_fields=RegionSerializer.Meta.brief_fields,
        required=False,
        allow_null=True
    )

As this approach is a bit verbose, it would be prudent to provide a shortcut in the form of a designated keyword argument when initializing the serializer. For instance, we could pass nested=True to imply that only the serializer's brief_fields should be included. (This would be handled under the base serializer class' __init__() method.)

class SiteSerializer(NetBoxModelSerializer):
    region = RegionSerializer(
        nested=True,
        required=False,
        allow_null=True
    )

Although this change will obviate the need for many of the current nested serializers, IMO we should retain these in the code base for at least one release cycle, to provide a smooth migration path for plugins which may still utilize them.

Justification

This approach provides two substantial benefits. First, it obviates the need to maintain dedicated nested serializers solely for the purpose of representing related objects. For instance, NestedManufacturerSerializer exists only to represent the related manufacturer when viewing a device or module type. With the approach above, it is no longer needed.

Second, we can now include arbitrary fields for additional context. For instance, when representing the site to which a rack is assigned, we might want to include its rack_count, and when representing a device, instead include its device_count.

It's worth noting that this does not automatically negate the need for all nested serializers. There are at least two scenarios where separate serializers must be defined:

• When representing recursive hierarchies. For example, RegionSerializer cannot be used to represent a region's parent region.
• To avoid circular logic. For example, DeviceSerialzer must represent the virtual chassis to which a device is assigned (if any), yet VirtualChassisSerializer must also represent its master device. A nested serializer must be used in one direction or the other to resolve this circular logic.