Import rerun-docs (#2284)

<!--
Open the PR up as a draft until you feel it is ready for a proper
review.

Do not make PR:s from your own `main` branch, as that makes it difficult
for reviewers to add their own fixes.

Add any improvements to the branch as new commits to make it easier for
reviewers to follow the progress. All commits will be squashed to a
single commit once the PR is merged into `main`.

Make sure you mention any issues that this PR closes in the description,
as well as any other related issues.

To get an auto-generated PR description you can put "copilot:summary" or
"copilot:walkthrough" anywhere.
-->

### What

Part of #2134

- [x] Move content from `rerun-io/rerun-docs` to `rerun-io/rerun/docs`
- [x] Upload all `rerun-io/rerun-docs/docs-media` to GCS (using `just
upload`) and update links
- [x] Test `landing` pointed to `rerun-io/rerun/<this PR>`

Preview: https://landing-lomuaznlh-rerun.vercel.app/docs

### Checklist
* [x] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [ ] I've included a screenshot or gif (if applicable)

<!-- This line will get updated when the PR build summary job finishes.
-->
PR Build Summary: https://build.rerun.io/pr/2284

.github/workflows/documentation.yaml

@@ -0,0 +1,31 @@
+name: Documentation
+
+on:
+  pull_request:
+  push:
+    branches:
+      - "main"
+
+permissions:
+  contents: read
+
+jobs:
+  spellcheck:
+    name: Spellcheck
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: streetsidesoftware/cspell-action@v2
+        with:
+          config: "docs/cspell.json"
+          files: "docs/**/*.md"
+  linkinator:
+    name: linkinator
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: JustinBeckwith/linkinator-action@v1
+        with:
+          paths: "docs/**/*.md"
+          linksToSkip: "https://crates.io/crates/rerun"
+

docs/README.md

@@ -0,0 +1,45 @@
+This is the high-level documentation for rerun that is hosted at https://www.rerun.io/docs
+
+## Other documentation
+API-level documentation is built from source-code. Python lives at [rerun_py](https://github.com/rerun-io/rerun/tree/main/rerun_py) and Rust in the individual [crates](https://github.com/rerun-io/rerun/tree/main/crates).
+
+## Contributions
+
+Contributions are welcome via pull-request. Note that even landed PRs will not deploy to the main site
+until the next time we roll out a site-update. We will generally to do this at least once per release.
+
+## Organization
+
+The site documentation lives in Markdown files inside [`/content`](./content).
+
+The entry point to the documentation is [`/content/index.md`](./content/index.md)
+
+Code examples can be rendered in multiple languages by placing them in `code-examples`, like so:
+
+```
+/docs
+    /code-examples
+        /my-example
+            /example.py
+            /example.rs
+```
+
+## Special syntax
+
+### Title and Navigation Order
+The display titles navigation order of documentation sections are managed by the Metadata at the top of the Markdown
+file:
+```
+---
+title: Examples
+order: 6
+---
+```
+
+
+### Code Examples
+
+Code-examples can be referenced in Markdown using this syntax:
+```
+code-example: my-example
+```

docs/code-examples/default-off-session/example.py

@@ -0,0 +1,2 @@
+import rerun as rr
+rr.init("my_app", default_enabled=False)

docs/code-examples/default-off-session/example.rs

@@ -0,0 +1 @@
+let recording = rerun::RecordingStreamBuilder::new("pouet").default_enabled(false);

docs/code-examples/extension-components/example.py

@@ -0,0 +1 @@
+rr.log_extension_components("your/entity/path", {"my-component": 0.9})

docs/code-examples/extension-components/example.rs

@@ -0,0 +1,20 @@
+use rerun::external::re_log_types::external::{arrow2, arrow2_convert};
+
+// First define your own component type.
+#[derive(arrow2_convert::ArrowField, arrow2_convert::ArrowSerialize)]
+#[arrow_field(transparent)]
+struct MyComponent(f32);
+
+impl rerun::Component for MyComponent {
+    fn name() -> rerun::ComponentName {
+        "ext.my-component".into()
+    }
+}
+
+// Then you can log it just like built-in components.
+fn log_custom(session: &mut Session) -> Result<(), rerun::MsgSenderError> {
+    MsgSender::new("your/entity/path")
+        .with_splat(MyComponent(0.9))?
+        .send(session)
+}
+c

docs/content/concepts.md

@@ -0,0 +1,6 @@
+---
+title: Concepts
+order: 2
+---
+
+For a deeper understanding of how your logging data can be organized and visualized, it is useful to learn about the underlying concepts in Rerun.

docs/content/concepts/apps-and-recordings.md

@@ -0,0 +1,20 @@
+---
+title: Application IDs and Recording IDs
+order: 8
+---
+
+## Application ID
+When you initialize rerun with [`rr.init`](https://ref.rerun.io/docs/python/latest/common/initialization/#rerun.init) you need to set an Application ID.
+
+Your Rerun Viewer will store the Blueprint based on this Application ID.
+This means that you can run your app and set up the viewer to your liking,
+and then when you run the app again the Rerun Viewer will remember how you set up your Space Views etc.
+
+## Recording ID
+Each time you start logging using Rerun, a random _Recording ID_ is generated.
+For instance, each `.rrd` file will have a unique Recording ID.
+
+This means you can have multiple recordings with different Recording IDs sharing the same application ID.
+
+If you want to log from multiple processes and want all the log data to show up
+together in the viewer, you need to make sure all processes use the same Recording ID.

docs/content/concepts/batches.md

@@ -0,0 +1,64 @@
+---
+title: Batch Data
+order: 4
+---
+
+Rerun has built-in support for batch data. Whenever you have a collection of things that all have the same type, rather
+than logging each element individually, you can log the entire collection together as a single "Batch". This provides
+significant benefits in terms of storage and compute.
+
+Some examples of batched data include points in a pointcloud, bounding boxes for detected objects, or tracked keypoints
+in a skeleton.
+
+In the Python APIs most of the log functions have both singular and plural signatures. The plural APIs, such as
+[log_points](https://ref.rerun.io/docs/python/latest/common/spatial_primitives/#rerun.log_points) generally take
+arrays as arguments, corresponding to the batches.
+
+## Terminology
+- When an entity is batched, the individual elements are called **"Instances"**.
+- Each Instance is identified within the Entity by its **"Instance Key"**.
+- When every Instance within an Entity has the same value for a component, that component is called a **"Splat"**. This
+  is a common enough case that there is special handling for it.
+  For instance, you can set all the colors of a point cloud to the same color using a Splat.
+- During queries, a batch always has a **"Primary"** component. The primary component is what determines
+  how many instances exist in the batch.
+
+## Restrictions
+
+When using batched entities there are a few restrictions:
+ - Because there is a one-to-one mapping between Batches and Entities:
+    - If data needs to span multiple Entity Paths, it needs to be split up into separate batches.
+    - If data needs to be split into multiple batches, each must be logged to a different path.
+ - Whenever you log a batched Entity, for any component that is updated, you must provide values for
+   every instance.
+    - It is not possible to only update a subset of the instances in the batch.
+
+## Batch join rules
+
+Rerun lets you choose which components in an entity you want to log at any point in time. If you don't log to a
+component, then in general it is not updated. For example, if you log a point cloud with positions and colors and then
+later log just new positions, when the viewer displays that point cloud it will still look up the *last* colors that
+were logged.
+
+This can be quite convenient since updating different components at different times puts far fewer restrictions on the
+organization of your code. It even means if a component on an entity is static, you only need to log it once.
+
+However, if a batch of colors, and a batch of positions have been logged at two different points in time, we need a way
+to know which point receives which color. This is what Rerun uses the "Instance Keys" for. When a component batch is
+logged it is always assigned a set of instance keys. By default, this key is based on the sequential index within the
+logged array.  When querying a batched component, the component-values are joined together based on these keys.
+Logically, this happens as a **left-join** using the "primary" component for the entity. For example, if you log 3
+points and then later log 5 colors, you will still only see 3 points in the viewer.
+
+In the future you will be able to specify the instance keys manually while logging ([#1309](https://github.com/rerun-io/rerun/issues/1309)).
+
+## Splats
+
+As mentioned, Rerun has special handling for "splats" within batches.  This is what happens when you mix arrays and
+single values in an API call. The non-array value is instead logged as a splat. Behind the scenes, the splat is stored
+as a single value rather than a full array. Then, when doing the join at lookup time the splat is repeated across
+every instance in the batch.
+
+
+
+

docs/content/concepts/entity-component.md

@@ -0,0 +1,62 @@
+---
+title: Entities and Components
+order: 1
+---
+
+## Data model
+The core of Rerun's data model is inspired by the ideas of the Entity Component System (ECS) architecture pattern. In
+short, an ECS is a composition-oriented framework in which Entities represent generic objects while Components describe
+data associated with those Entities.
+
+ * Entities are the "things" that your log statements talk about. They are represented by the
+   [Entity Path](entity-path.md) string that is the first argument to most of the logging APIs.
+ * Components, however, are what contains the data that is associated with those "things". For example, position, color,
+   pixel data, etc.
+### Logging data
+All of the data that you log within rerun is mapped to the concepts of entities and components.
+For example, consider the case of logging a point
+```python
+rr.log_point("my_point", position=[32.7, 45.9], color=[255, 0, 0])
+```
+This log statement is recording data about the Entity "my_point". The data will ultimately be stored in two components.
+In this case `point2d` and `colorrgba`.  Behind the scenes, this function is simply making records in the data store
+that these component values are associated with the "my_point" entity.
+
+### Primitives
+Later, the Space View for spatial types queries the data store for all of the entities that have a `point2d` component.
+In this case it would find the "my_point" entity. This query additionally returns the `colorrgba` component because that
+component is associated with the same entity.
+
+We call this pre-defined collection of components a _Primitive_.
+Primitives do not have any significance to the data model itself, but are important for the Viewer to understand
+how data should be displayed.
+
+The assorted logging APIs all simply set different combinations of components on some specified entity, and the
+corresponding space views look for entities with these components in the data store.  
+For more information on the different primitives and how they relate to components see the
+[Primitives reference](../reference/primitives.md).
+
+### Extension Components
+Your entity could have any number of other components as well. This isn't a problem. Any components that
+aren't relevant to the scene that the space view is drawing are safely ignored. In fact, Rerun even allows you to log your
+own components.
+
+In Python this is done via [log_extension_components](https://ref.rerun.io/docs/python/latest/common/extension_components/#rerun.log_extension_components)
+, whereas in Rust you implement the [Component](https://docs.rs/rerun/latest/rerun/trait.Component.html) trait.
+
+code-example: extension-components
+
+
+
+### Empty Entities
+An Entity, without Components, is nothing more than an identity (represented by its Entity
+Path). It contains no data, and has no type. When you log a piece of data, all that you are doing is setting the values
+of one or more *Components* associated with that *Entity*. 
+
+## ECS Systems
+In most ECS architectures, there is a third concept we haven't touched on: Systems are processes which operate on the
+Entities based on the Components they possess.
+
+Rerun does not currently have formalized Systems, although the patterns employed by the Rerun Space Views are very much
+"System like" in their operation. Proper Systems may be a feature investigated in the future
+([#1155](https://github.com/rerun-io/rerun/issues/1155)).

docs/content/concepts/entity-path.md

@@ -0,0 +1,53 @@
+---
+title: The Entity Path Hierarchy
+order: 1
+---
+
+## Entity Paths
+As mentioned in the [Entity Component](entity-component.md) overview, all Entities within Rerun have a unique _Entity Path_.
+
+The first argument to each log function is this path. Each time you log to a specific entity path you will update the entity, i.e. log a new instance of it along the timeline. Each logging to a path must be of the same type (you cannot log an image to the same path as a point cloud).
+
+Rerun treats these paths as being arranged in a hierarchy with the "/" character acting as a separator between path
+elements. The conventional path semantics including concepts of "root" and "parent" / "child" generally apply.
+
+When writing paths in logging APIs the leading "/" is omitted.
+
+Note that there is no path-level distinction between "file-like" and "directory-like" concepts. Any path may be an
+entity, and entities may be direct children of other entities. For example:
+```
+rr.log_image("image", img)
+rr.log_points("image/points", points)
+```
+
+However, it is also acceptable to leave implicitly "empty" elements in your paths as well.
+```
+rr.log_image("camera/image", img)
+rr.log_points("camera/image/detections/points", points)
+```
+Nothing needs to be explicitly logged to `"camera"` or `"camera/image/detection"` to make the above valid.
+
+#### Path parts
+
+A path can look like this: `camera/"left"/detection/#42/bbox`. Each part (between the slashes) can either be:
+
+* A name (e.g. `camera`), intended for hard-coded names.
+* A `"quoted string"`, intended for dynamic strings, like serials numbers.
+* An integer, intended for hashes or similar.
+* A number sequence, prefixed by `#`, intended for indices.
+* A UUID.
+
+So for instance, `foo/bar/#42/5678/"CA426571"/a6a5e96c-fd52-4d21-a394-ffbb6e5def1d` is a valid path.
+
+
+### Path Hierarchy Functions
+Path hierarchy plays an important role in a number of different functions within Rerun:
+
+ * With the [Transform System](spaces-and-transforms.md) the `transform` component logged to any Entity always describes
+the relationship between that Entity and its direct parent.
+ * When resolving the meaning of `class_id` and `keypoint_id` components, Rerun uses the Annotation Context from the nearest ancestor in the hierarchy.
+ * When adding data to [Blueprints](../reference/viewer/blueprint.md), it is common to add a path and all of its descendants.
+ * When using the `log_cleared` API, it is possible to mark an entity and all of its descendants as being cleared.
+ * In the future, it will also be possible to use path-hierarchy to set default-values for descendants.
+   [#1158](https://github.com/rerun-io/rerun/issues/1158)
+