Fix four routes with auth_desired misimplemented.

PR #374 removed `@auth_required` from a number of routes and changed
those which used their `v` parameters to `v=None` and removed the `v`
parameter from those which didn't internally use it. 1841134b47

PR #392 re-added `@auth_desired` to those routes to ensure the
templates rendered with awareness of the current logged-in user
(matters for search, header bar, etc). 9f042c1aeb

However, 500 errors occurred on /random_post, /random_user, /id/<uid>,
and /u/<username>. Those were the four which had their `v` parameter
removed entirely. This has been re-added, which fixes the bug.

The way to understand auth_required vs auth_desired is that they are
nearly identical, with the sole difference than auth_required
checks if v is None and aborts with 401 if so. This means that
auth_desired routes must handle the v=None case. They are the same in
that they always try to give a `v` kwarg to the decorated function,
which was the root cause of those four routes erroring.

Recommended style: the vast majority of routes which return a rendered
template should be auth_desired, because the top-level templates often
draw extensively from `v` state even when the route handler does not.
When a route is either auth_desired or auth_required, it should have a
`v` parameter, which we typically give as the first positional
parameter.

files/routes/front.py

@@ -468,7 +468,7 @@ def changeloglist(v=None, sort="new", page=1, t="all", site=None):
 
 @app.get("/random_post")
 @auth_desired
-def random_post():
+def random_post(v):
 
 	p = g.db.query(Submission.id).filter(Submission.deleted_utc == 0, Submission.is_banned == False, Submission.private == False).order_by(func.random()).first()
 
@@ -480,7 +480,7 @@ def random_post():
 
 @app.get("/random_user")
 @auth_desired
-def random_user():
+def random_user(v):
 	u = g.db.query(User.username).order_by(func.random()).first()
 	
 	if u: u = u[0]