Change Code Insights url hierarchy

[vovakulikov]

Closes https://github.com/sourcegraph/sourcegraph/issues/21012

This PR changes URLs of code insights pages

Old URLs

/insights
/insights/create-intro
/insights/create-search-insight
/insights/create-lang-stats-insight

New URLs

/* dashboard page */
/insights  

/* Intro insight creation page */
/insights/create 

/* Search based insight creation UI page */
/insights/create/search

/* Code stats (lang-stats) insight creation UI page */
/insights/create/lang-stats

[vovakulikov]

@valerybugakov I remember that we had a conversation about routes URL management. IRTL we wanted to add something like this

/**
 * Enum with all insights related pages URLs
 */
export enum InsightsRouteUrl {
    dashboard = '/insights',
    creation = '/insights/create',
    creationInsight = '/insights/create/:type',
}

But can you please elaborate on this a bit more. Should we use absolute paths for insight sub routing or would it be better if we stick with absolute only paths?

[tjkandala]

LGTM

[valerybugakov]

Cross-posting here messages from our Slack DM for visibility about shared routes:

As for https://github.com/sourcegraph/sourcegraph/issues/20693, I thought about the app-wide shared constant that should be used everywhere instead of the raw strings:

const routes = {
  userProfile: '/:organization/user/:userId/profile'
}

<Route path={routes.userProfile} />

For routes with params we need some kind of a factory function to fill params in the actual links:

<Link to={routesFactory.userProfile({ userId: 123, organization: 'github' })} />

Ideally, all paths should be absolute. It will simplify things because there won't be a need to keep a context of where a router is mounted. It should be easy to achieve in one application because we have full control over all parts of it.

Let me know if you see any use-cases that don't play well with this approach. You have more hands-on experience with routing in this repo already 🙂