Should event.navigationType for reloads be "reload" or "replace"?

[domenic]

In working on #112 this came up. Currently it's specced as "replace", under the mental model that a reload is a same-URL replace.

Pros for treating reloads as "replace":

• Simpler mental model: replace/push/traverse are all very distinct and carve up the universe of navigations nicely.
• The distinction between appHistory.navigate(appHistory.current.url, { replace: true }) and appHistory.reload()/location.reload() is not very important and developers probably want to treat them similarly.

Potential reasons to separate reloads into a new "reload" type:

• Maybe navigate handlers actually want to handle reloads specially, e.g. clearing UI state or something to give the user a "fresh" experience.
• Browsers treat reloads somewhat distinct from same-URL replaces in a couple cases and surfacing this might be good:
  • APIs like service workers and navigation timing
  • Some of the details around scroll position restoration seem to differ, although not very interoperably.

[Yay295]

APIs like service workers and navigation timing

Since the PerformanceNavigation.type/PerformanceNavigationTiming.type property has a distinct value for reloads, I think it would also make sense to distinguish reloads in this API. Or maybe even use that API in this API. The Navigation Timing API is still in development though so I don't know what exactly that would look like.