feat: Add device attributes to ApplicationUp messages

[vlasebian]

Summary

References #5879

Changes

• Add attributes field to ApplicationUplink
• Add attributes field to ApplicationUplinkNormalized
• Add locations, version_ids, network_ids and attributes fields to ApplicationJoinAccept
• Add locations, version_ids, network_ids and attributes fields to ApplicationDownlink
• Add locations, version_ids, network_ids and attributes fields to ApplicationDownlinkFailed
• Add locations, version_ids, network_ids and attributes fields to ApplicationInvalidatedDownlinks
• Add locations, version_ids, network_ids and attributes fields to ApplicationServiceData

Testing

TODO

Steps

...

Results

Regressions

...

Notes for Reviewers

...

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[vlasebian]

@johanstokking @KrishnaIyer there is a note in the implementation plan that I don't get completely:

[...] a new binary compatible variant of ApplicationDownlink [2]. [..]

[2] ApplicationDownlink is also used during submission, and it does not make much sense to allow users to submit these fields while pushing a downlink.

I understand that this change has to be made as it does not make sense to set these fields when the application sends a downlink to the end device (the fields should be set on end device creation and not modified through uplinks or downlinks).

Does this mean that a whole new message must be defined where these fields are included? Something like:

message EnrichedApplicationDownlink {
  ApplicationDownlink downlinks = 1;
  // End device location metadata, set by the Application Server while handling the message.
  map<string, Location> locations = 3;

  // End device version identifiers, set by the Application Server while handling the message.
  EndDeviceVersionIdentifiers version_ids = 4;

  // Network identifiers, set by the Network Server that handles the message.
  NetworkIdentifiers network_ids = 5;

  // Attributes for devices, set by the Application Server while handling the message.
  map<string, string> attributes = 6 [(validate.rules).map = {
    max_pairs: 10,
    keys: {
      string: {
        pattern: "^[a-z0-9](?:[-]?[a-z0-9]){2,}$",
        max_len: 36
      }
    },
    values: {
      string: {max_len: 200}
    }
  }];

  // next: 7
}

And by binary compatible variant, does that mean serialisable?