Add life cycle information to response of plants API calls

[tschawax]

Tasks

• [ ] existing model PlantsSummaryDto (backend/src/model/dto.rs) has to be extended with a new list-field life_cycle (backend/src/model/enum/life_cycle.rs), so that the endpoint invocations of /api/plants/{id} and /api/plants also contain a plant's life cycle in the response

• [ ] life_cycle is a list containing any combination of its 3 possible values (annual, biennial, perennial) or just an empty list in case a plant has no life cycle value in the DB

• endpoint definition of plants endpoints can be found here: backend/src/controller/plants.rs

• currently, the response when calling /api/plants/{id} (or /api/plants for a list of plants) looks like this:

  {
  "id": 2107,
  "unique_name": "Abelia triflora",
  "common_name_en": [
  "indian abelia"
  ],
  "spread": "wide"
  }

• new response should look like this:

  {
  "id": <number>,
  "unique_name": <unique_name>,
  "common_name_en": [
  <common_name_en>
  ],
  "spread": <spread>,
  --> "life_cycle": [] || ["annual","biennial","perennial"] <--
  }

Use case

plants_layer

Related Pull request

724

[markus2330]

@horenso Thx for creating this issue! Please update top post:

• We should also include common_name_de, see #433.
• Spread will be an integer, see #822. This is also needed for UC area of plants, which you will probably do as next UC (after copy&paste).

Did you look through all UC? Is it a good idea to stuff everything to PlantsSummaryDto? For #476 we will need nearly all of plant's data.

[markus2330]

when creating dates can already be calculated, see #724

This issue will only be needed when cycle information will be made available in plant attributes #476.