chore(docs): more cleanup (#16442)

# Changes

- Removes an unneeded path in `tutorials/codealong`, fixes all those
links
- Removes an entire tutorial "Node.js app that interacts with contracts"
which was exactly the same as "Getting started with Aztec.js". The only
difference was that the former copy-pasted the Token contract, whereas
the latter imported it from `@aztec/noir-contracts.js`. Insane.

As a replacement:
- Adds a tiny tutorial aptly named `Deploy a Token Contract` which does
the same thing. No #include_code code snippets, this may backfire but it
would be easy enough to make the tutorial testable (like we do for
Barretenberg docs).
- Spins off a how-to guide on how to compile and deploy a random
contract

I think we can benefit from not leaning too heavily on code snippets.
Both `aztec.nr` and `aztec.js` are much stabler now and actually can't
change much as we rush towards mainnet. Since our #1 prio is fixing
docs, this will make us move faster.

Author: alejoamiras

docs/docs-words.txt

@@ -345,3 +345,5 @@ woooh
 zcash
 Zcash
 Zybil
+nothin
+whoooaa

docs/docs/aztec/concepts/accounts/index.md

@@ -73,7 +73,7 @@ A request for executing an action requires:
 - The initial function to call (usually `entrypoint`).
 - The arguments (which encode the private and public calls to run as well as any signatures).
 
-Read more about how to write an account contract [here](../../../developers/tutorials/codealong/contract_tutorials/write_accounts_contract.md).
+Read more about how to write an account contract [here](../../../developers/tutorials/contract_tutorials/write_accounts_contract.md).
 
 ### Non-standard entrypoints
 
@@ -101,7 +101,7 @@ Account contracts are tightly coupled to the wallet software that users use to i
 
 When a user wants to interact with the network's **public** state, they need to deploy their account contract. A contract instance is considered to be publicly deployed when it has been broadcasted to the network via the canonical `ContractInstanceRegistry` contract, which also emits a deployment nullifier associated to the deployed instance.
 
-However, to send fully **private** transactions, it's enough to initialize the account contract (public deployment is not needed). The default state for any given address is to be uninitialized, meaning a function with the [initializer annotation](../../../developers/tutorials/codealong/contract_tutorials/nft_contract.md#initializer) has not been called. The contract is initialized when one of the functions marked with the `#[initializer]` annotation has been invoked. Multiple functions in the contract can be marked as initializers. Contracts may have functions that skip the initialization check (marked with `#[noinitcheck]`).
+However, to send fully **private** transactions, it's enough to initialize the account contract (public deployment is not needed). The default state for any given address is to be uninitialized, meaning a function with the [initializer annotation](../../../developers/tutorials/contract_tutorials/nft_contract.md#initializer) has not been called. The contract is initialized when one of the functions marked with the `#[initializer]` annotation has been invoked. Multiple functions in the contract can be marked as initializers. Contracts may have functions that skip the initialization check (marked with `#[noinitcheck]`).
 
 Account deployment and initialization are not required to receive notes. The user address is deterministically derived from the encryption public key and the account contract they intend to deploy, so that funds can be sent to an account that hasn't been deployed yet.
 

docs/docs/aztec/concepts/fees.md

@@ -61,7 +61,7 @@ These are:
 
 A fee payer will have bridged fee-juice from L1. On Aztec this fee asset is non-transferrable, and only deducted by the protocol to pay for fees. A user can claim bridged fee juice and use it to pay for transaction fees in the same transaction.
 
-The mechanisms for bridging is the same as any other token. For more on this concept see the start of the [Token Bridge Tutorial](../../developers/tutorials/codealong/js_tutorials/token_bridge.md) where it describes the components and how bridging works (under the hood this makes use of [portals](https://docs.aztec.network/aztec/concepts/communication/portals)).
+The mechanisms for bridging is the same as any other token. For more on this concept see the start of the [Token Bridge Tutorial](../../developers/tutorials/js_tutorials/token_bridge.md) where it describes the components and how bridging works (under the hood this makes use of [portals](https://docs.aztec.network/aztec/concepts/communication/portals)).
 
 ### Payment methods
 
@@ -84,4 +84,4 @@ The fees section of the protocol specification explains this distribution of fee
 
 More comprehensive technical details for implementers will be available from the updated protocol specifications soon.
 
-For a guide showing ways to pay fees programmatically, see [here](../../developers/guides/js_apps/pay_fees).
+For a guide showing ways to pay fees programmatically, see [here](../../developers/guides/js_apps/how_to_pay_fees).

docs/docs/aztec/concepts/wallets/index.md

@@ -7,7 +7,7 @@ description: Overview of wallet responsibilities in Aztec including account mana
 
 On this page we will cover the main responsibilities of a wallet in the Aztec network.
 
-Refer to [writing an account contract](../../../developers/tutorials/codealong/contract_tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account.
+Refer to [writing an account contract](../../../developers/tutorials/contract_tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account.
 
 Go to [wallet architecture](./architecture.md) for an overview of its architecture and a reference on the interface a wallet must implement.
 

docs/docs/aztec/smart_contracts/contract_creation.md

@@ -84,4 +84,4 @@ This modular approach to contract deployment creates a flexible system that supp
 
 ## Further reading
 
-To see how to deploy a contract in practice, check out the [dapp development tutorial](../../developers/tutorials/codealong/js_tutorials/simple_dapp/index.md).
+To see how to deploy a contract in practice, check out the [dapp development tutorial](../../developers/tutorials/js_tutorials/aztecjs-getting-started.md).

docs/docs/aztec/smart_contracts/contract_structure.md

@@ -39,4 +39,4 @@ Here's a common layout for a basic Aztec.nr Contract project:
 ```
 
 - See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages).
-- You can review the structure of a complete contract in the NFT contract tutorial [here](../../developers/tutorials/codealong/contract_tutorials/nft_contract.md).
+- You can review the structure of a complete contract in the NFT contract tutorial [here](../../developers/tutorials/contract_tutorials/nft_contract.md).

docs/docs/aztec/smart_contracts/functions/index.md

@@ -7,7 +7,7 @@ description: Overview of Aztec contract functions, including private, public, an
 
 Functions serve as the building blocks of smart contracts. Functions can be either **public**, ie they are publicly available for anyone to see and can directly interact with public state, or **private**, meaning they are executed completely client-side in the [PXE](../../concepts/pxe/index.md). Read more about how private functions work [here](./attributes.md#private-functions-private).
 
-For a more practical guide of using multiple types of functions, follow the [NFT tutorial](../../../developers/tutorials/codealong/contract_tutorials/nft_contract.md).
+For a more practical guide of using multiple types of functions, follow the [NFT tutorial](../../../developers/tutorials/contract_tutorials/nft_contract.md).
 
 Currently, any function is "mutable" in the sense that it might alter state. However, we also support static calls, similarly to EVM. A static call is essentially a call that does not alter state (it keeps state static).
 

docs/docs/aztec/smart_contracts/functions/visibility.md

@@ -7,7 +7,7 @@ description: Understand function visibility modifiers in Aztec and how they affe
 
 In Aztec there are multiple different types of visibility that can be applied to functions. Namely we have `data visibility` and `function visibility`. This page explains these types of visibility.
 
-For a practical guide of using multiple types of data and function visibility, follow the [NFT tutorial](../../../developers/tutorials/codealong/contract_tutorials/nft_contract.md).
+For a practical guide of using multiple types of data and function visibility, follow the [NFT tutorial](../../../developers/tutorials/contract_tutorials/nft_contract.md).
 
 ### Data Visibility
 

docs/docs/aztec/smart_contracts_overview.md

@@ -26,4 +26,4 @@ There are no plans for EVM compatibility or to support Solidity in Aztec. The pr
 
 ## Further reading
 
-Jump in and write your first smart contract [here](../developers/tutorials/codealong/contract_tutorials/counter_contract.md)
+Jump in and write your first smart contract [here](../developers/tutorials/contract_tutorials/counter_contract.md)

docs/docs/aztec/writing_efficient_contracts.md

@@ -50,7 +50,7 @@ When private functions are called, the overhead of a "kernel circuit" is added e
 
 #### Profiling using FlameGraph
 
-Measuring the gate count across a private function can be seen at the end of the counter tutorial [here](../developers/tutorials/codealong/contract_tutorials/counter_contract#investigate-the-increment-function). Full profiling and flamegraph commands explained [here](../developers/guides/smart_contracts/profiling_transactions).
+Measuring the gate count across a private function can be seen at the end of the counter tutorial [here](../developers/tutorials/contract_tutorials/counter_contract#investigate-the-increment-function). Full profiling and flamegraph commands explained [here](../developers/guides/smart_contracts/profiling_transactions).
 
 ### L2 Data costs