refactor: Reintroduce strictly typed AccountId

[miraclx]

Resolves #4600

• Reintroduces refactor: Introduce strictly typed and assuredly validated AccountId #4440 (reverted in Revert "refactor: Introduce strictly typed and assuredly validated Ac… #4601)

  This PR introduces a strictly typed structure - AccountId that enforces account ID validation.
  This way, we can ensure validity and thereby fail fast before an invalid account name is used.

  This also, optionally, ensures validation on {,de}serialization so, yeah..

  The structure is defined within its own self-contained crate near-account-id to allow for easy publishing.
  The extra dependencies - borsh, serde are made optional to allow the crate to be lightweight enough to be depended upon.

  Within nearcore, the structure is reexported via near_primitives::AccountId and the crate via near_primitives{,_core}::account::id with default features (borsh, serde) but you can opt-out of those by depending on it directly.

  Resolves Define AccountId to hold a contract of being valid #2074, supersedes feat(core): Defined AccountId to hold a contract of being valid #2831.

  Testing Plan

  • Existing unit tests pass with minor updates
  • Nayduck tests pass without modifications
  • Manually ensured that the protocol is not changed

• Fixes issue of loading genesis with records of invalid AcountId-s in AccessKey-s

Nayduck

http://nayduck.eastus.cloudapp.azure.com:3000/#/run/1943

Testing Plan

• Manually booted a testnet node to ensure genesis loads properly and that no further AccountId-related issues occur.
• Ensured unit tests pass with no further updates
• Nayduck tests pass without modifications

[bowenwang1996]

@miraclx the PR is very large. Could you point to where exactly the fix is?

[frol]

@miraclx Please, provide more context about the issue with the Access Keys in the genesis file (it is even better if you provide the specific examples with the invalid account ids we have there)

@bowenwang1996 I asked @miraclx to prepare the PR in such a way that the first commit is a squash-commit from the previous PR, and the second commit is the patch on top of that, so see the second commit.

[miraclx]

We have invalid AccountId-s in .records[].AccessKey occurring several times in the genesis config. Here's two of those cases..

• Case 1: Empty String (ErrorKind::TooShort)

  {
    "AccessKey": {
      "account_id": "bentiancai629",
      "public_key": "ed25519:FSgxX7YwuCveCeYqsSAB3sD8dgdy3XBWztCQcEjimpaN",
      "access_key": {
        "nonce": 0,
        "permission": {
          "FunctionCall": {
            "allowance": "100000000",
            "receiver_id": "", <--
            "method_names": []
          }
        }
      }
    }
  },

• Case 2: Caps characters (ErrorKind::Invalid)

  {
    "AccessKey": {
      "account_id": "jfaulkner",
      "public_key": "ed25519:HBonxN3DJpnTSiy5DF4NN7eAfcm7mV26PNhHW42Lb5k6",
      "access_key": {
        "nonce": 0,
        "permission": {
          "FunctionCall": {
            "allowance": "10000000000000000000000",
            "receiver_id": "NEAR_wallet_app", <--
            "method_names": []
          }
        }
      }
    }
  }, 

With the previous behavior not doing any validation, this is an impediment to our initiative of using strictly typed AccountId's everywhere. To remedy this, we retain the previous behavior and strictly define this field as a String.