Improve the ticking modal performance by removing the dependency on history loading

[brendanheywood]

In my experience the biggest bottle neck when loading the new ticking interface is blocking waiting on the previous ticking data for this route to be loaded to this api endpoint eg:

https://www.thecrag.com/api/node/id/1234567/mysummary?cookieAuth=1

1. I think this call could be completely eliminated, the page you are on already knows that you have ticked something before. I haven't tried to reverse engineer it but my guess is that the only reason is needs this call is to look up the previous quality rating you gave it before. A) This data could already be loaded in the main index page as part of the tick data for your previous ticks and re-use so you don't need the extra ajax call, and also B) It could be made completely redundant - I don't think it needs to be set as the default at all. I would regularly give a different ascent of the same route different ratings, I am rating that ascent not the route. If it was dirty or wet or whatever that affects my subjective experience on the day. If I tick it multiple times only my latest rating matters, and if I don't rate it then that's also fine. I think just like the tick type for each attempt this should be left with no default for each ascent.

It would be a pretty small change with a potentially large impact on the overall ticking experience.

A few other low hanging fruit which would also make a difference to the ticking ux:

2. I like to tick the routes in the order I climbed them, potentially repeating the same route in a session, so I tick them one at a time. The modal which pops up after each ticking showing the cpr to me adds no value and I ignore it and it slows me down.
3. When I tick I scroll up and down, find the route, the ticking modal pops up, and in the background the scroll state jumps around so when I am finished I'm not where I was. It appears to always scroll up about half a page.