feat(view-sharing): Add new endpoint to delete single view

[MichaelSun48]

As part of the shared view project, we will now need to be able to delete a single view.

We can't use the old endpoint because that one doesn't contain a viewId url param, so we need a new endpoint specifically to access a single resource.

[mrduncan]

What's the reasoning for not just letting them do this and deleting the star?

[MichaelSun48]

We're moving the delete and duplicate options (the two options that alter the number of views) to within the all views page. The idea is that you should be more intentional about changing the state of your views (though this may change in the future).

This also saves some complexity wrt making the positions correct. We don't have to worry about that as much if the only entry point to creating/deleting a starred view is via the bulk update function, but if we allow someone to directly delete/create a starred view, then we'll need to also decrement/increment (respectively) the position of the views after it.

[malwilley]

Hmm I'm not sure that this is necessary for deletion. We did discuss that we shouldn't allow deleting from the list of starred views, but I think you should still be able to delete a view without first unstarring it. The positions should be okay to remain the same since the ordering will be unchanged, right?

[MichaelSun48]

Yeah that's true, deleting a starred would always retain the correct ordering of the views. Though I think it may still be worth it to update the positions anyways to make sure they are always perfectly in sync with the positions on the frontend.

I'm afraid of a future where we forget that its possible for positions to be in a desynced state, and then we make a change that relies on them being in sync, causing the ordering to get all out of wack. I could totally be too paranoid, but that would be very messy situation to fix. I'm curious what y'all think though.

[codecov]

❌ 1 Tests Failed:

Tests completed	Failed	Passed	Skipped
23771	1	23770	290

View the top 1 failed test(s) by shortest run time

tests.snuba.tagstore.test_tagstore_backend.TagStorageTest::test_get_group_tag_key_generic

Stack Traces | 6.97s run time

#x1B[1m#x1B[.../snuba/tagstore/test_tagstore_backend.py#x1B[0m:554: in test_get_group_tag_key_generic
    assert (
#x1B[1m#x1B[.../tagstore/snuba/backend.py#x1B[0m:479: in get_group_tag_key
    return self.__get_tag_key_and_top_values(
#x1B[1m#x1B[.../tagstore/snuba/backend.py#x1B[0m:207: in __get_tag_key_and_top_values
    raise TagKeyNotFound if group is None else GroupTagKeyNotFound
#x1B[1m#x1B[31mE   sentry.tagstore.exceptions.GroupTagKeyNotFound#x1B[0m

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}