Forum allow non-editable posts

[conectado]

Fix forum state bloat in #2196

In this PR I implement what we decided to do to solve the problem of state bloat in the forum pallet here.

Originally, we've solved the problem of state bloat in the forum pallet, by requiring a deposit for thread and post creation. Furthermore, the thread stored within its structure all the posts, using this, to delete a thread it was constant in time and when a thread was deleted all the deposit from all posts was given to the thread deleter(normally the thread creator).

However, this had the problem of making the structure of a thread to big which we would need to deal with in the weight functions, see: #2234

To solve this we wanted to return each post to its own storage. The problem if we make the thread deletion as a side effect delete all its posts, it'd be too costly, on the other side, if we require the creator of the post to delete each of their posts that would generate too much traffic.

To solve the last problem we decided that we can have both editable and non-editable posts. Editable posts work as the posts have always worked, non-editable don't need to occupy storage, so there is no deletion after a thread is deleted. We expect most posts to be non-editable and that would mean that this would greatly reduce traffic and dependence on each user deleting their posts.

Furthermore, we allow users who are not the posters to delete other users posts given this 2 conditions:

• The thread has been deleted
• It has passed PostLifeTime since the post was last edited

In this way we make sure that a post will be delted by other users opportunistically.

To motivate a user to delete their post, now deleting a post recover its original deposit. And the thread only recover its original deposit(not from all posts).

Included in this PR

To introduce the changes I described above I needed to include the following:

• Change delete_thread to only be used by thread creator instead of only the moderator/lead as to prevent a moderator/lead from deleting a thread just to recover its deposit(also to allow the correct functioning for a user to recover their deposit by deleting it). If a moderator/lead wants to remove a thread they need to use moderate_thread which slash the deposit instead of giving it to any one account.
• Add delete_posts which allows deletion of posts by the user(allowing multiple post deletion at the same time to reduce the cost of doing so and reducing traffic)
• Remove any verification for reactions to valid posts, that is left for query nodes.

Furthermore, we removed the storage limits for threads and posts since that is dealt with by the deposits.

Companion handbook PR: Joystream/handbook#38

[bedeho]

Great job, just some minor tweaks as we agreed

1. Allow user signaling of whether a post and thread should be hidden or not when deleting them from storage. Non-post authors who delete cannot signal this
2. Validated stickied threads, when setting, to make sure the threads have been created in the past, irrespective of whether they were subsequently removed, or hidden.

[bedeho]

Grea job.