Implement CSV export of model data using REST API

[jathanism]

Proposed Changes

The following changes are proposed to implement support for export (rendering) and import (parsing) of CSV data using the REST API:

Implementation

• We will use djangorestframework-csv
• The renderer rest_framework_csv.renderers.PaginatedCSVRenderer must be used
  • This returns the current page of results without the next, previous, count
  • We will still need to solve how to get all objects vs. just the current page of objects for this file format.
• This enables any API view to render CSV by passing the ?format=csv query parameter or setting Accept: text/csv in the request headers.

Nested object representations

• By default these are flattened and indexed with dotted notation
  • (e.g. Status.content_types gets exploded into content_types.0, content_types.1,
  • This is not desirable. We want flat representations as a comma-separated string e.g.
    • ["dcim.device", "dcim.interface"] becomes…
    • "dcim.device,dcim.interface" in a CSV field
• Bulk import done (using bulk_create) and bulk update (using bulk_update) existing API endpoints and should “just work” but this needs to be tested.
  • This is done using the rest_framework_csv.parsers.CSVParser
• Custom fields (being a nested representation) need to be accounted for
  • Current implementation is 1 header per e.g. cf_{custom_field.slug}

Models

• Remove csv_headers attribute
• Remove to_csv() method

Views

• Remove queryset_to_csv() method
• The correct API call needs to be accounted for to export ALL objects via CSV in keeping with current UI behaviors.

Justification

This has been decided to be the path forward for eliminating bespoke import/export code in the Nautobot core in exchange for something closer to the way we're already doing import/export of objects using JSON via the REST API. Ideally this will require us to maintain little to no extra code to provide support for CSV inputs.

Additionally, because the REST API already supports bulk-create and bulk-update using the REST API (predicated on the serializer objects that know how to parse and render model data) these operations should also work relatively out of the box with little changes required, outside of those highlighted above in the proposed changes.

Keep in Mind

• FK nested representations can/should stop at just exporting a PK and will be replaced with a natural key after Epic: Correct Existing Natural Keys, Supporting Uniqueness Constraints #1574 is complete

[lampwins]

The renderer rest_framework_csv.renderers.PaginatedCSVRenderer must be used

• This returns the current page of results without the next, previous, count
• We will still need to solve how to get all objects vs. just the current page of objects for this file format.

I am not sure if I am interpreting this correctly, but exporting by page is unimportant to me. Instead, I would expect exporting by the filter that is applied. I.e., if I have no filter I would expect all records to be exported. If I have a filter with 182 results and my page size set to 50, I would expect all 182 results in the export.

We could look later at enhancements like only exporting those rows that have been selected (checkbox).

[glennmatthews]

Blocked by #3042.

[glennmatthews]

Implemented for 2.0 by #3722.