As a user I can add a list of things to be done within a task so that I can track the goals to be met or use the feature as a shopping list

[Adhalianna]

Acceptance criteria:

• Each task must have an optional field for the universally unique list ID.
• By default the list (if available) should be fetched with a task it is attached to on GET requests fetching the task.
• If a task does not have a list attached a link to list creation should be provided with the task. Otherwise it should provide links for list update (PUT), list removal (DELETE), list fetching (GET), or list creation (POST).
• The order of items in the list should be preserved and well defined. The indexes (starting from 1) should be used in the API paths that allow update (PUT), creation (POST) or removal (DELETE) of a specific list item.
• When a new list item is created it should be returned to the user after POST request with a corrected or added index number. The index numbers should always be sequential (no gaps allowed). The API does not have to support reordering (swapping items when a user updates an item to have a different index number). PUT updates with changed index number should in such situation error with status 409 ("Conflict").
• When an item from a middle of the list is removed the indexes should be reassigned to preserve the order.
• The list item must be a data type that has an information about its state (completed or not completed), index number (within the list) and a UTF-8 text of length up to 256 bytes. The text cannot be an empty string.
• The API for marking items within the list as completed or not should reflect the API for marking tasks completed as closely as possible. It should use the same HTTP verbs, the same or analogous field names and/or the same query parameters (if applicable).

[Adhalianna]

Some remarks after taking look at those criteria after some time since those were written:

• The first item on the list qualifies rather as implementation detail and probably shouldn't be here
• That first point is rather problematic: there is no reason to have a separate table for the list if there will ever be only one for each task. The list can be implemented as an array in PostgreSQL.
• PUT updates with changed index number should in such situation error with status 409 ("Conflict"). - this constraint simply makes a poor user experience and it shouldn't be here.

The first point is the most unfortunate in my opinion - as far as the API ergonomics go having an id mapping to a list which is in 1-to-1 relation with the task anyway makes no sense, querying the lists table through a join is less efficient and implementation is not even simpler this way. Because of that I will start with ignoring that criteria.

[Adhalianna]

Alright, now I remember what the list id was for - the list items need a boolean field marking whether it is completed or not and while it is supposedly possible to make diesel work with PostgreSQL composite types (according to this issue, nvm, I do not want a link here, it would lead people looking for more info on that in here for nothing) we have no performance requirements (as part of the WAT2023 project) and so it is not worth the work at the moment. It will be easier to make task and list items have 1-to-many mapping with list table working as join table.

[Adhalianna]

So finally it ended up being the array of composite types - implemented in commit closing the issue #56