docs: repoint puppet.com/docs links to OpenVox equivalents (openbolt)

Completes the openbolt portion of the puppet.com link cleanup. These are
all in committed narrative pages; the 9 generated reference pages are
managed upstream and not touched here.

- puppet/* -> /openvox/latest/* (cross-collection), with renames
  (puppet_strings -> openvox_strings, release_notes_puppet -> release_notes,
  writing_custom_functions -> functions_basics). Several anchors corrected
  to the OpenVox page versions, since OpenVox pages use different ids
  (e.g. #module-structure, #puppet-lookup, #classes-and-defined-resource-types,
  lang_data_abstract#data); anchors with no OpenVox equivalent section
  drop to the page (format_report, release_notes, subsystem_catalog_compilation).
- bolt/* -> within-collection relative links (inventory_file -> inventory_files).
- puppetdb/* -> /openvoxdb/latest/*; facter -> /openfact/latest/.
- pdk/* -> /pdk.html, the OpenVox-hosted PDK page (Puppet has moved newer
  PDK behind a paywall, so the puppet.com links were partly dead anyway).
- Remove dead Puppet Enterprise references: unlink the PE control-repo tip
  in projects.md, and drop the "Puppet Enterprise" entry from the related-
  products list in bolt.md.
- Keep the lone puppet_index link in developer_updates.md (a historical
  reference to upstream Puppet 7).

Verified: jekyll build passes; every repointed target and anchor resolves
(checked link anchors against target page ids, not just page existence);
git diff --check clean.

Part of #295

Signed-off-by: Michael Harp <mike@mikeharp.com>

Author: miharp

docs/_openbolt_5x/applying_manifest_blocks.md

@@ -30,13 +30,13 @@ limitations](#manifest-block-limitations).
 ## Applying manifest blocks from the command line
 
 Similar to the [`puppet apply`
-command](https://puppet.com/docs/puppet/latest/man/apply.html), which applies a
+command](/openvox/latest/man/apply.html), which applies a
 standalone Puppet manifest to a local system, you can use Bolt to apply
 Puppet manifests to remote targets.
 
 Manifest blocks require facts to compile. When Bolt applies Puppet manifests, it
 automatically installs the packages necessary to run the apply command and
-gathers facts using [facter](https://puppet.com/docs/facter/latest/), making the
+gathers facts using [facter](/openfact/latest/), making the
 facts available to the manifest block. Bolt also identifies targets that do not
 have Puppet agents and runs the [`openvox_bootstrap::install`
 task](https://forge.puppet.com/puppet/openvox_bootstrap) to install the agent.
@@ -104,9 +104,9 @@ Manifest only contains definitions and will result in no changes on the targets.
 📖 **Related information**  
 
 - [Defining and declaring
-  classes](https://puppet.com/docs/puppet/latest/lang_classes.html)
+  classes](/openvox/latest/lang_classes.html)
 - [Defining and declaring defined
-  types](https://puppet.com/docs/puppet/latest/lang_defined_types.html)
+  types](/openvox/latest/lang_defined_types.html)
 
 ### How manifest blocks are applied
 
@@ -163,7 +163,7 @@ Manifest blocks require facts to compile. If your plan includes a manifest
 block, use the `apply_prep` function in your plan _before_ your manifest block.
 The `apply_prep` function installs the packages necessary to run the apply
 command and gathers facts by running
-[facter](https://puppet.com/docs/facter/latest/), making the facts available to
+[facter](/openfact/latest/), making the facts available to
 the manifest block. The `apply_prep` function also identifies the targets that
 do not have Puppet agents and runs the [`puppet_agent::install`
 task](https://forge.puppet.com/puppetlabs/puppet_agent) to install the agent.
@@ -216,9 +216,9 @@ returns the reports generated by applying the catalog on each target.
 ### Return value
 
 The `apply` function returns a [`ResultSet`
-object](https://puppet.com/docs/bolt/latest/bolt_types_reference.html#resultset)
+object](bolt_types_reference.html#resultset)
 that contains an [`ApplyResult`
-object](https://puppet.com/docs/bolt/latest/bolt_types_reference.html#applyresult)
+object](bolt_types_reference.html#applyresult)
 for each target. 
 
 ```puppet
@@ -232,7 +232,7 @@ $results.each |$result| {
 
 The [`ApplyResult` object](bolt_types_reference.html#applyresult) includes a
 `report` method that returns a hash representation of the
-[`Puppet::Transaction::Report`](https://puppet.com/docs/puppet/latest/format_report.html)
+[`Puppet::Transaction::Report`](/openvox/latest/format_report.html)
 object. Each property on the object corresponds to a key with the same name in
 the report hash. However, not every property is presented in the hash for every
 result. Only properties that have a value from the apply are present in the
@@ -290,7 +290,7 @@ hand, uses the Bolt default thread pool controlled by the `concurrency` option.
 
 ## Using Hiera data in a manifest block
 
-Use [Hiera](https://puppet.com/docs/puppet/latest/hiera_intro.html) to separate
+Use [Hiera](/openvox/latest/hiera_intro.html) to separate
 configuration from context-specific data, where context might be fact-based or the
 name of a target.
 
@@ -299,7 +299,7 @@ name of a target.
 Hiera is a key-value configuration data look up system, used for separating data
 from Puppet code. You use Hiera data to implicitly override default class
 parameters. You can also explicitly look up data from Hiera via the [`lookup`
-function](https://puppet.com/docs/puppet/latest/function.html#lookup):
+function](/openvox/latest/function.html#lookup):
 
 ```puppet
 plan do_thing() {
@@ -316,19 +316,19 @@ You can change this with the `hiera-config` key in a Bolt config file or the
 
 Following the Hiera 5 convention, the default data directory is relative to
 `hiera.yaml` at `<PROJECT DIRECTORY>/data`. For configuration file examples, see [Configuring
-Hiera](https://puppet.com/docs/puppet/latest/hiera_config_yaml_5.html). Bolt 
+Hiera](/openvox/latest/hiera_config_yaml_5.html). Bolt
 will not automatically load any Hiera data from this directory. If you want to load data from a
 data file you must set the relevant paths in your Hiera config.
 
 > **Note**: The target name is made available to Hiera as `trusted.certname`. You can learn more about
   [interpolating variables into Hiera config
-  here](https://puppet.com/docs/puppet/latest/hiera_merging.html#interpolate_puppet_variable).
+  here](/openvox/latest/hiera_merging.html#interpolate-a-puppet-variable).
 
 If a custom data provider is used, such as `hiera-eyaml`, which allows you to
 encrypt your data, the gem dependencies must be available to Bolt. See [Install
 gems with Bolt packages](bolt_installing.html#).
 
-[Hiera interpolations](https://puppet.com/docs/puppet/latest/hiera_merging.html#hiera_interpolation)
+[Hiera interpolations](/openvox/latest/hiera_merging.html#interpolation)
 are not supported in Bolt outside of apply blocks, because Hiera data is looked up per-target and
 plans do not run in a per-target context. If you want to use Hiera to look up data outside of an apply
 block, you can use a [plan hierarchy](#using-hiera-data-in-a-manifest-block).

docs/_openbolt_5x/automating_windows_targets.md

@@ -110,10 +110,10 @@ task runner executes the task.
 creating the `.ps1` file in a directory called `tasks`. Alternatively, you can
 use Puppet Development Kit (PDK), to create a task by using the [`pdk new
 task`
-command](https://puppet.com/docs/pdk/1.x/pdk_reference.html#pdk-new-task-command).
+command](/pdk.html).
 If you’re going to be creating a lot of tasks, using PDK is worth getting to
 know. For more information, see the [PDK
-documentation.](https://puppet.com/docs/pdk/1.x/pdk_overview.html)
+documentation.](/pdk.html)
 
 1.  In the `bolt-guide` directory, create the following subdirectories:
     ```

docs/_openbolt_5x/bolt.md

@@ -68,9 +68,8 @@ you are not required to install any agent software.
     </p>
     <p>Docs for related Puppet products
         <ul>
-            <li><a class="xref" target="_blank" href="https://puppet.com/docs/puppet/latest/index.html">Open source Puppet</a></li>
-            <li><a class="xref" target="_blank" href="https://puppet.com/docs/pe/latest/pe_user_guide.html">Puppet Enterprise®</a></li>
-            <li><a class="xref" target="_blank" href="https://puppet.com/docs/pdk/latest/pdk.html">Puppet Development Kit</a></li>
+            <li><a class="xref" target="_blank" href="/openvox/latest/index.html">Open source Puppet</a></li>
+            <li><a class="xref" target="_blank" href="/pdk.html">Puppet Development Kit</a></li>
         </ul>
     </p>
     <p>Why and how people are using Bolt

docs/_openbolt_5x/bolt_installing_modules.md

@@ -279,7 +279,7 @@ requirement.
 
 > 🔩 **Tip**: For information on how to specify module versions, see the Puppet
 > documentation on [Specifying
-> versions](https://puppet.com/docs/puppet/latest/modules_metadata.html#specifying-versions).
+> versions](/openvox/latest/modules_metadata.html#version-specifiers-in-module-metadata).
 
 ## Install Forge modules from an alternate Forge
 

docs/_openbolt_5x/bolt_inventory_reference.md

@@ -40,7 +40,7 @@ config:
 ### `facts`
 
 A map of system information, also known as
-[facts](https://puppet.com/docs/puppet/latest/lang_facts_and_builtin_vars.html),
+[facts](/openvox/latest/lang_facts_and_builtin_vars.html),
 for the implicit `all` group. Facts set at this level apply to all groups and
 targets in the inventory file.
 
@@ -138,7 +138,7 @@ groups:
 ### `facts`
 
 A map of system information, also known as
-[facts](https://puppet.com/docs/puppet/latest/lang_facts_and_builtin_vars.html),
+[facts](/openvox/latest/lang_facts_and_builtin_vars.html),
 for the group. Facts set at this level apply to all groups and targets under
 the group.
 
@@ -301,7 +301,7 @@ targets:
 ### `facts`
 
 A map of system information, also known as
-[facts](https://puppet.com/docs/puppet/latest/lang_facts_and_builtin_vars.html),
+[facts](/openvox/latest/lang_facts_and_builtin_vars.html),
 for the target.
 
 - **Type:** Hash

docs/_openbolt_5x/bolt_running_scripts.md

@@ -12,7 +12,7 @@ target's operating system. This includes any scripting language the target can r
 
 There are a few ways to reference scripts for Bolt to load:
 - _Preferred_: Using a [Puppet file
-  reference](https://puppet.com/docs/puppet/latest/types/file.html#file-attribute-source) of the
+  reference](/openvox/latest/types/file.html#file-attribute-source) of the
   form `<module>/scripts/myscript.sh`. Puppet file references load files from specific directories in
   modules that are on [the modulepath](modules.html#modulepath). You can load a script from the
   `files/` directory using `<module>/files/myscript.sh`, but the preferred place for scripts to be

docs/_openbolt_5x/developer_updates.md

@@ -16,7 +16,7 @@ we're making.
 
 Currently, you can point to the location of a script or file as an absolute path
 or use a [Module-style load
-path](https://puppet.com/docs/puppet/latest/file_serving.html). Puppet
+path](/openvox/latest/file_serving.html). Puppet
 module-style paths use the syntax `<module_name>/<path_to_file>`, where the `<module_name>` is the
 name of the module on the modulepath to load from, and `<path_to_file>` is the path to the file
 within the `<module_name>/files/` subdirectory. For example, if you provided Bolt with
@@ -166,7 +166,7 @@ compiled a list of expected changes and removals.
   plans.
 
   To read more about the changes in Puppet 7, see the [Puppet 7 release
-  notes](https://puppet.com/docs/puppet/7.0/release_notes_puppet.html#release_notes_puppet_x-0-0).
+  notes](/openvox/latest/release_notes.html).
 
 - **Ship with Ruby 2.7**
 

docs/_openbolt_5x/experimental_features.md

@@ -64,7 +64,7 @@ project-level policy named `myproject::user`, run:
 
 Bolt creates an empty class in the project's `manifests/` directory that you can
 populate with code. Policy names must follow [class naming
-conventions](https://puppet.com/docs/puppet/7/lang_reserved.html#classes-and-defined-resource-type-names).
+conventions](/openvox/latest/lang_reserved.html#classes-and-defined-resource-types).
 
 
 Example output:
@@ -105,7 +105,7 @@ Modulepath
 ### Applying policies to targets
 
 Applying policies is similar to [applying Puppet
-code](https://puppet.com/docs/bolt/latest/applying_manifest_blocks.html), with
+code](applying_manifest_blocks.html), with
 the addition that you can apply one or more policies at a time. The Bolt
 commands for applying policies accept a single policy name or a comma-separated
 list of policy names to apply to a list of one or more targets. 
@@ -736,8 +736,8 @@ Each `ResourceInstance` has the following attributes:
 | Parameter | Type | Description |
 | --- | --- | --- |
 | `target` | The target that the resource is for. | `Target` |
-| `type` | The [type of the resource](https://puppet.com/docs/puppet/latest/type.html). This can be either the stringified name of the resource type or the actual type itself. For example, both `"file"` and `File` are acceptable. | `Variant[String[1], Type[Resource]]` |
-| `title` | The title, or [namevar](https://puppet.com/docs/puppet/latest/type.html#namevars-and-titles), of the resource. | `String[1]` |
+| `type` | The [type of the resource](/openvox/latest/type.html). This can be either the stringified name of the resource type or the actual type itself. For example, both `"file"` and `File` are acceptable. | `Variant[String[1], Type[Resource]]` |
+| `title` | The title, or [namevar](/openvox/latest/type.html#namevars-and-titles), of the resource. | `String[1]` |
 | `state` | The _observed state_ of the resource. This is the point-in-time state of the resource when it is queried. | `Hash[String[1], Data]` |
 | `desired_state` | The _desired state_ of the resource. This is the state that you want the resource to be in. | `Hash[String[1], Data]` |
 | `events` | Resource events that are generated from reports. | `Array[Hash[String[1], Data]]` | 

docs/_openbolt_5x/getting_started_with_bolt.md

@@ -67,7 +67,7 @@ New-BoltProject -Name my_project
 
 To use Bolt plans or tasks, your Bolt project must use a specific directory
 structure. The directory structure of a Bolt project is closely tied to [Puppet
-modules](https://puppet.com/docs/puppet/latest/modules_fundamentals.html).
+modules](/openvox/latest/modules_fundamentals.html).
 Because your plan will install Apache, you need an `apache` module directory.
 Your `apache` directory needs `files` and `plans` subdirectories.
 

docs/_openbolt_5x/glossary.md

@@ -21,7 +21,7 @@ the `apply_prep` plan function. See [`apply_prep`](#apply_prep).
 
 📖 **Related information**
 
-- [Applying Puppet code](https://puppet.com/docs/bolt/latest/applying_manifest_blocks.html)
+- [Applying Puppet code](applying_manifest_blocks.html)
 
 ## apply_prep
 
@@ -31,7 +31,7 @@ path. The `puppet-agent` package and facts are required for an `apply`.
 
 📖 **Related information**
 
-- [Applying Puppet code](https://puppet.com/docs/bolt/latest/applying_manifest_blocks.html)
+- [Applying Puppet code](applying_manifest_blocks.html)
 - [`apply_prep` example](plan_functions.html#apply_prep)
 
 ## catalog
@@ -49,7 +49,7 @@ specific target, and generated by a target.
 
 📖 **Related information**
 
-- [Catalog compilation](https://puppet.com/docs/puppet/latest/subsystem_catalog_compilation.html#subsystem_catalog_compilation)
+- [Catalog compilation](/openvox/latest/subsystem_catalog_compilation.html)
 
 ## controller
 
@@ -101,7 +101,7 @@ separate data from your code.
 
 📖 **Related information**
 
-- [How to use Hiera](https://puppet.com/docs/puppet/7/hiera_intro.html)
+- [How to use Hiera](/openvox/latest/hiera_intro.html)
 - [Using bolt with Hiera](hiera.html)
 
 ## inventory
@@ -198,8 +198,8 @@ into Bolt and Puppet, or custom functions
 📖 **Related information**
 
 - [Bolt built-in functions](plan_functions.html)
-- [Puppet built-in functions](https://puppet.com/docs/puppet/7/function.html)
-- [More information on custom functions](https://puppet.com/docs/puppet/7/writing_custom_functions.html)
+- [Puppet built-in functions](/openvox/latest/function.html)
+- [More information on custom functions](/openvox/latest/functions_basics.html)
 
 ## plugin