chore(ci): Mirror Aztec-nr (#2270)

solution for:
- #2265
- handles renaming noir-libs -> aztec-nr
- renames what was aztec-nr to just aztec

aztec-nr lives here (with full history):
- https://github.com/AztecProtocol/aztec-nr
- once this is merged it can be made public and a nice readme put on it

.github/workflows/mirror_repos.yml

@@ -12,7 +12,7 @@ concurrency:
 on:
   schedule:
     # Run the workflow every night at 2:00 AM UTC.
-    cron: '0 2 * * *'
+    - cron: '0 2 * * *'
 
 jobs:
   mirror-to-docs-repo:
@@ -77,3 +77,24 @@ jobs:
             git commit --amend -m "$(git log -1 --pretty=%B) [skip ci]"
             git push
           fi
+
+  mirror-to-aztec-nr-repo:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+          token: ${{ secrets.AZTEC_BOT_GITHUB_TOKEN }}
+      - name: Push to aztec-nr repo
+        run: |
+          SUBREPO_PATH=yarn-project/aztec-nr
+          git config --global user.name AztecBot
+          git config --global user.email tech@aztecprotocol.com
+
+          if ./scripts/git_subrepo.sh push $SUBREPO_PATH --branch=main; then
+            git fetch # in case a commit came after this
+            git rebase origin/master
+            git commit --amend -m "$(git log -1 --pretty=%B) [skip ci]"
+            git push
+          fi

build_manifest.json

@@ -102,7 +102,7 @@
       "^l1-contracts/",
       "^yarn-project/l1-artifacts/",
       "^yarn-project/noir-contracts/",
-      "^yarn-project/noir-libs/",
+      "^yarn-project/aztec-nr/",
       "^yarn-project/noir-compiler/",
       "^yarn-project/yarn-project-base/",
       "^yarn-project/yarn.lock"
@@ -199,7 +199,7 @@
     "dockerfile": "noir-contracts/Dockerfile.build",
     "rebuildPatterns": [
       "^yarn-project/noir-contracts/",
-      "^yarn-project/noir-libs/"
+      "^yarn-project/aztec-nr/"
     ]
   },
   "noir-contracts": {
@@ -208,7 +208,7 @@
     "dockerfile": "noir-contracts/Dockerfile",
     "rebuildPatterns": [
       "^yarn-project/noir-contracts/",
-      "^yarn-project/noir-libs/"
+      "^yarn-project/aztec-nr/"
     ]
   },
   "noir-compiler": {

docs/docs/concepts/foundation/accounts/keys.md

@@ -71,7 +71,7 @@ In a future version, encryption keys will be differentiated between incoming and
 
 An application in Aztec.nr can access the encryption public key for a given address using the oracle call `get_public_key`, which you can then use for calls such as `emit_encrypted_log`:
 
-#include_code encrypted /yarn-project/noir-libs/value-note/src/utils.nr rust
+#include_code encrypted /yarn-project/aztec-nr/value-note/src/utils.nr rust
 
 :::info
 In order to be able to provide the public encryption key for a given address, that public key needs to have been registered in advance. At the moment, there is no broadcasting mechanism for public keys, which means that you will need to manually register all addresses you intend to send encrypted notes to. You can do this via the `registerRecipient` method of the Aztec RPC server, callable either via aztec.js or the CLI. Note that any accounts you own that have been added to the RPC server are automatically registered.
@@ -83,7 +83,7 @@ In addition to deriving encryption keys, the privacy master key is used for deri
 
 An application in Aztec.nr can request a nullifier from the current user for computing the nullifier of a note via the `get_secret_key` oracle call:
 
-#include_code nullifier /yarn-project/noir-libs/value-note/src/value_note.nr rust
+#include_code nullifier /yarn-project/aztec-nr/value-note/src/value_note.nr rust
 
 ### Scoped keys
 

docs/docs/dev_docs/contracts/events.md

@@ -44,11 +44,11 @@ await aztecRpc.registerRecipient(completeAddress);
 
 To emit encrypted logs first import the `emit_encrypted_log` utility function inside your contract:
 
-#include_code encrypted_import /yarn-project/noir-libs/value-note/src/utils.nr rust
+#include_code encrypted_import /yarn-project/aztec-nr/value-note/src/utils.nr rust
 
 Then you can call the function:
 
-#include_code encrypted /yarn-project/noir-libs/value-note/src/utils.nr rust
+#include_code encrypted /yarn-project/aztec-nr/value-note/src/utils.nr rust
 
 
 ### Unencrypted Events

docs/docs/dev_docs/contracts/portals/main.md

@@ -37,7 +37,7 @@ As time passes, a sequencer will see your tx, the juicy fee provided and include
 To consume the message, we can use the `consume_l1_to_l2_message` function within the `context` struct. 
 The `msg_key` is the hash of the message produced from the `sendL2Message` call, the `content` is the content of the message, and the `secret` is the pre-image hashed to compute the `secretHash`.
 
-#include_code context_consume_l1_to_l2_message /yarn-project/noir-libs/aztec-noir/src/context.nr rust
+#include_code context_consume_l1_to_l2_message /yarn-project/aztec-nr/aztec/src/context.nr rust
 
 Computing the `content` might be a little clunky in its current form, as we are still adding a number of bytes utilities. A good example exists within the [Non-native token example](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/src/contracts/non_native_token_contract/src/hash.nr).
 
@@ -63,7 +63,7 @@ The portal must ensure that the sender is as expected. One way to do this, is to
 
 To send a message to L1 from your Aztec contract, you must use the `message_portal` function on the `context`. When messaging to L1, only the `content` is required (as field). 
 
-#include_code context_message_portal /yarn-project/noir-libs/aztec-noir/src/context.nr rust
+#include_code context_message_portal /yarn-project/aztec-nr/aztec/src/context.nr rust
 
 When sending a message from L2 to L1 we don't need to pass recipient, deadline, secret nor fees. Recipient is populated with the attached portal and the remaining values are not needed as the message is inserted into the outbox at the same time as it was included in a block (for the inbox it could be inserted and then only included in rollup block later). 
 

docs/docs/dev_docs/contracts/state_variables.md

@@ -28,15 +28,15 @@ The BoolSerialisationMethods is part of the Aztec stdlib:
 
 It contains methods that instruct its PublicState wrapper how to serialise and deserialise a boolean to and from a Field, which is the data type being saved in the public state tree.
 
-The Aztec stdlib provides serialization methods for various common types. Check [here](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-libs/aztec-noir/src/types/type_serialisation) for the complete list.
+The Aztec stdlib provides serialization methods for various common types. Check [here](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec-nr/aztec/src/types/type_serialisation) for the complete list.
 
 ### Custom types
 
 It's possible to create a public state for any types. Simply define methods that guide the PublicState wrapper in serialising the custom type to field(s) to store in the public state tree, and deserialising the field(s) retrieved from the tree back to the custom type.
 
 The methods should be implemented in a struct that conforms to the following interface:
 
-#include_code TypeSerialisationInterface /yarn-project/noir-libs/aztec-noir/src/types/type_serialisation.nr rust
+#include_code TypeSerialisationInterface /yarn-project/aztec-nr/aztec/src/types/type_serialisation.nr rust
 
 For example, to create a public state for the following type:
 
@@ -118,7 +118,7 @@ Notes are the fundamental elements in the private world.
 
 A note should conform to the following interface:
 
-#include_code NoteInterface /yarn-project/noir-libs/aztec-noir/src/note/note_interface.nr rust
+#include_code NoteInterface /yarn-project/aztec-nr/aztec/src/note/note_interface.nr rust
 
 The interplay between a private state variable and its notes can be confusing. Here's a summary to aid intuition:
 
@@ -243,7 +243,7 @@ Because of this limit, we should always consider using the second argument `Note
 
 `NoteGetterOptions` encapsulates a set of configurable options for filtering and retrieving a selection of notes from a database:
 
-#include_code NoteGetterOptions /yarn-project/noir-libs/aztec-noir/src/note/note_getter_options.nr rust
+#include_code NoteGetterOptions /yarn-project/aztec-nr/aztec/src/note/note_getter_options.nr rust
 
 Developers can design instances of `NoteGetterOptions`, to determine how notes should be filtered and returned to the functions of their smart contracts.
 

docs/docs/dev_docs/contracts/syntax.md

@@ -2,7 +2,7 @@
 
 [Noir](https://noir-lang.org/) is a language which is agnostic to proof systems and use cases. Rather than baking Aztec-specific keywords and smart contract types directly into Noir (which would break this agnosticism), we have developed a library -- written in Noir -- whose types and methods provide rich smart contract semantics.
 
-On top of [Noir's stdlib](https://noir-lang.org/standard_library/array_methods), we provide [Aztec.nr](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/noir-libs) for writing contracts on Aztec.
+On top of [Noir's stdlib](https://noir-lang.org/standard_library/array_methods), we provide [Aztec.nr](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec-nr) for writing contracts on Aztec.
 
 Aztec.nr contains abstractions which remove the need to understand the low-level Aztec protocol. Notably, it provides:
 

docs/docs/dev_docs/dapps/testing.md

@@ -133,7 +133,7 @@ To query storage directly, you'll need to know the slot you want to access. This
 
 Private state in the Aztec Network is represented via sets of [private notes](../../concepts/foundation/state_model.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value.
 
-#include_code value-note-def yarn-project/noir-libs/value-note/src/value_note.nr rust
+#include_code value-note-def yarn-project/aztec-nr/value-note/src/value_note.nr rust
 
 We can query the RPC server for all notes encrypted for a given user in a contract slot. For this example, we'll get all notes encrypted for the `owner` user that are stored on the token contract address and on the slot we calculated earlier. To calculate the actual balance, we extract the `value` of each note, which is the first element, and sum them up.
 

docs/docs/dev_docs/dapps/tutorials/contract_deployment.md

@@ -19,8 +19,8 @@ Then, open the `contracts/private_token/Nargo.toml` configuration file, and add
 
 ```toml
 [dependencies]
-aztec = { git="https://github.com/AztecProtocol/aztec-packages", tag="master", directory="yarn-project/noir-libs/noir-aztec" }
-value_note = { git="https://github.com/AztecProtocol/aztec-packages", tag="master", directory="yarn-project/noir-libs/value-note" }
+aztec = { git="https://github.com/AztecProtocol/aztec-packages", tag="master", directory="yarn-project/aztec-nr/noir-aztec" }
+value_note = { git="https://github.com/AztecProtocol/aztec-packages", tag="master", directory="yarn-project/aztec-nr/value-note" }
 ```
 
 Last, copy-paste the code from the `PrivateToken` contract into `contracts/private_token/main.nr`:

docs/docs/dev_docs/getting_started/noir_contracts.md

@@ -61,7 +61,7 @@ compiler_version = "0.1"
 type = "contract"
 
 [dependencies]
-aztec = { git="https://github.com/AztecProtocol/aztec-packages", tag="master", directory="yarn-project/noir-libs/aztec-noir" }
+aztec = { git="https://github.com/AztecProtocol/aztec-packages", tag="master", directory="yarn-project/aztec-nr/aztec" }
 ```
 
 You are now ready to write your own contracts! 

docs/docs/dev_docs/wallets/writing_an_account_contract.md

@@ -32,7 +32,7 @@ Public Key:  0x0ede151adaef1cfcc1b3e152ea39f00c5cda3f3857cef00decb049d283672dc71
 
 The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: 1) authenticating the transaction and 2) executing calls. It receives a `payload` with the list of function calls to execute, as well as a signature over that payload.
 
-#include_code entrypoint-struct yarn-project/noir-libs/aztec-noir/src/entrypoint.nr rust
+#include_code entrypoint-struct yarn-project/aztec-nr/aztec/src/entrypoint.nr rust
 
 :::info
 Using the `EntrypointPayload` struct is not mandatory. You can package the instructions to be carried out by your account contract however you want. However, the entrypoint payload already provides a set of helper functions, both in Noir and Typescript, that can save you a lot of time when writing a new account contract.
@@ -48,7 +48,7 @@ We authenticate the transaction. To do this, we serialise and Pedersen-hash the
 
 Last, we execute the calls in the payload struct. The `execute_calls` helper function runs through the private and public calls included in the entrypoint payload and executes them:
 
-#include_code entrypoint-execute-calls yarn-project/noir-libs/aztec-noir/src/entrypoint.nr rust
+#include_code entrypoint-execute-calls yarn-project/aztec-nr/aztec/src/entrypoint.nr rust
 
 Note the usage of the `_with_packed_args` variant of [`call_public_function` and `call_private_function`](../contracts/functions.md#calling-functions). Due to Noir limitations, we cannot include more than a small number of arguments in a function call. However, we can bypass this restriction by using a hash of the arguments in a function call, which gets automatically expanded to the full set of arguments when the nested call is executed. We call this _argument packing_.
 

yarn-project/aztec-nr/.gitrepo

@@ -0,0 +1,12 @@
+; DO NOT EDIT (unless you know what you are doing)
+;
+; This subdirectory is a git "subrepo", and this file is maintained by the
+; git-subrepo command. See https://github.com/ingydotnet/git-subrepo#readme
+;
+[subrepo]
+	remote = git@github.com:AztecProtocol/aztec-nr.git
+	branch = master
+	commit = f662901567fa19e205062d84180763f06cddd641
+	method = merge
+	cmdver = 0.4.6
+	parent = 8df8fa7351ca79c022e2eb7dddfd7cf0145876df