Move into NCS

[coderbyheart]

Today we have decided that the best solution is to move this repository into the applications folder of NCS. It does not yet represent a good example for an out-of-tree NCS application and we can also benefit from being a fully integrated application because it requires all changes to NCS to be compatible with the firmware (or the firmware to be adapted in a PR). For customers it means they always get one place to find a working Asset Tracker reference implementation, for each release and for bleeding edge.

This yields the following tasks:

• create a PR with the source code inside a folder named asset_tracker_v2 in applications
• move end-to-end code into separate repository (so it can be maintained outside of NCS)
• update the Actions definitions to run in the sdk-nrf repository
• move the remaining issues to the bifravst repository (and label them firmware)
• set up a new process to provide pre-build firmware
• update the instructions on how to acquire the pre-build firmware
• update the instructions how to continuously build, as well as how to automate HEX file publishing
• place a link in the README of this repository
• archive this repository

See bifravst/bifravst#56

[coderbyheart]

The biggest impact the move into NCS has is that we can no longer use automated semantic releases: https://bifravst.github.io/bifravst/docs/guides/AutomateHEXFileBuilding.html ... this also affects that we no longer provide pre-build HEX files that users can use to connect to their instance: https://bifravst.github.io/bifravst/docs/firmware/UsingPrebuildImages.html

I think both is super valuable for customers, so I plan to add a NordicSemiconductor/asset_tracker_v2 repo, that releases the asset_tracker_v2 continuously, using the approach a customer would do: copy the source files from asset_tracker_v2 to a blank repo and start customizing it.