API: More flexibility when updating subscribers

[codecat]

Is your feature request related to a problem? Please describe.

When using the /api/subscribers/{id} endpoint to update a subscriber (using PUT), according to the docs:

Note: All parameters must be set, if not, the subscriber will be removed from all previously assigned lists.

This is not flexible at all, and kinda makes the endpoint a bit useless:

• You can't only update a single value, you have to give it the entire subscriber. This is doable by first fetching the subscriber before making the PUT request, but this introduces a race condition where you might end up unexpectedly changing things in the subscriber.
• The behavior of preconfirm_subscriptions is not defined in the documentation, but judging by the code (I might be wrong here) it behaves the same as the "create subscriber" endpoint, in which it will either force unconfirmed or confirmed for every list subscription. That means you can't ever update a subscriber without also forcing subscription confirmations.

As it stands now, this is a huge blocker for us in implementing Listmonk.

Describe the solution you'd like

I would like an update endpoint where I can specify specifically what I want to update. For example, a request like this would only update a subscriber's name, as it's the only field included in the request:

// PUT /api/subscribers/123
{ "name": "John" }

For attributes, I'd expect it to allow me to change single values within the map rather than the entire structure of attributes at once. For example, the following query that will only update foo and leave any other values unchanged.

// PUT /api/subscribers/123
{
  "attribs": { "foo": 123 }
}

For deleting attributes, maybe setting values to null could work, but I can see there being a potential compatibility problem if someone might use null as real attribute values.

List memberships are already possible to manage through /api/subscribers/lists, so I don't think it's even needed for the subscriber update endpoint.

Obviously I'd expect this to be on a "v2" route or something, as not to break older clients.