feat: add nodeBlsKey support

[leopaul36]

Linked issues

• Fix Add support for nodeBlsKey for nodeId secrets #92

Dependencies

• https://github.com/AshAvalanche/ash-api-rs/pull/5

Changes

• Added support for parsing nodeBlsKey from a file path
• Added read_file_bytes_base64 to follow the same standard as the generate-bls-key -o command
• Update the blueprints to add BLS keys

Additional comments

• I added a following section to Cargo.toml to have a local dev dependency to ash_api. Not sure if it's the best way to go (EDIT: looks like cargo check does not like this).

[Nuttymoon]

About your additional comment.

In this setup, we cannot run unit tests if the agent doesn't have access to ash-api-rs. We could give access to AshAvalancheBot to the repo and clone ash-api-rs in the CI pipeline.

[Nuttymoon]

patch is not appropriate here. We can just add a path field to the existing ash_cli dependency.

See https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies

[leopaul36]

Yes we had that until 1ff639b

Should we just go back to this?

[Nuttymoon]

FYI adding the nodeBlsKey field to the local node IDs won't impact the network validations (and the nodes won't have any BLS key registered on the P-Chain).

[leopaul36]

FYI adding the nodeBlsKey field to the local node IDs won't impact the network validations (and the nodes won't have any BLS key registered on the P-Chain).

Should we remove the BLS keys from the blueprints then?

[Nuttymoon]

FYI adding the nodeBlsKey field to the local node IDs won't impact the network validations (and the nodes won't have any BLS key registered on the P-Chain).

Should we remove the BLS keys from the blueprints then?

I don't think it has any negative impact + it's mandatory on the Juju side. We should just make sure that whenever they add static BLS keys to the local network genesis we change those.