GitLab

* add completion for `-b` or `--fqbn` for every command

* add completion for `-l` or `--protocol`
But does only work for connected boards and do not list every protocol installed

* the previous implementation was working only with a board connected to the pc
RPC was not exposing that functionality

* add static completion for `--log-level, `--log-format` and `--format`

* add completion for `-P` or `--programmer` & fix typo

* add completion for `core uninstall`
maybe could be done better (filter and remove the manually installed ones)

* add completion for `core install` and `core download`

* add completion for `lib uninstall`

* add completion for `lib install`, `lib download`

* add completion for `lib examples`

* add completion for `config add`, `config remove`, `config delete` and `config set`

* add completion for `lib deps`

* add tests

* enhance the completion for `config add` and `config remove`

* add description completion suggestion for core, lib, fqbn, programmer

* add completion also for `-p` or `--port` flag

* remove the `toComplete` parameter from all the completion functions
as of now this parameter is useless because if a string is typed in the terminal it cannot be swapped with a different one.
For example if I write `arduino-cli compile -b avr<TAB><TAB>` the completion function returns all elements starting with `arduino:avr...`.
So the completions are not showed because they cannot be swapped with a string that starts differently.
The only shell which seems to support this seems to be zsh

* fixes after rebase

* update docs

* add `-b` or `--fqbn` completion for the monitor command and tests

* apply suggestions from code review

* fixes after rebase

[skip-changelog] Drop `go.rice` library in favor of golang native `embed` (available from go1.16) (#1513)

* Removed 'go.rice' library in favor of 'embed'

* fix i18n

* #1456 - Add "new sketch" in gRPC .proto, regenerate .pg.go. Use "user" dir for sketches created via gRPC

* #1456 - Avoid using hardcoded extension (address comment).

* #1456 - Add optional dir field in the request, use it.

* #1456 - Use go-paths-helper

* Use gRPC function from CLI to create new sketch
Co-authored-by: Silvano Cerza <silvanocerza@gmail.com>

In the event an Arduino boards platform is deprecated by the maintainer, it will be useful to clearly communicate this
fact to the user and ensure they will easily find a preferred alternative platform. In order to facilitate this, a
`packages[*].platforms[*].deprecated`field was added to the Arduino package index format and this information is used to
enhance the user interfaces of the official Arduino development software.

This useful feature is now documented in the Arduino package index specification.

* [skip changelog] Correct context key name in "Sync Labels" workflow

Incorrect context key name resulted in impossible to satisfy conditional, meaning the dry run determination code was
solely dependent on the check for whether the workflow was triggered from the default branch name.

* [skip changelog] Sync labels in write mode on schedule trigger

In order to facilitate the testing and review of proposed changes to the repository label infrastructure, the
"Sync Labels" template workflow does a dry run when triggered under conditions that indicate it would not be appropriate
to make real changes to the repository's labels. The changes that would have resulted are printed to the log, but not
actually made.

One of the criteria used to determine "dry run" mode usage is whether the event occurred on the repository's default
branch. A trigger on a development branch or for a pull request should not result in a change to the labels.
It turns out that GitHub does not define a `github.event.repository.default_branch` context item when a workflow is
triggered by a `schedule` event. This resulted in the workflow always running in "dry run" mode on a `schedule` trigger.
Since `schedule` and `repository_dispatch` triggers are only permitted for the default branch, there is no need to check
whether the event's ref matches the default branch and it is safe to always run in write mode on these events.

Add gRPC interface function to request user fields supported by a board/protocol combination (#1503)

Add support for pluggable monitor (tracks branch `feature/pluggable-monitor`)

* Add --fqbn parameter to monitor command

* Add support for pluggable monitors with explicit recipe in platform.txt

* increase logging

* fix i18n

* Factored pluggable monitor creation

* Factored out code duplication

* EnumerateMonitorPortSettings does require only protocol

* Monitor.Open does require only address and protocol

* Added GetPortAddressAndProtocol helper

* fix i18n

* Apply suggestions from code review
Co-authored-by: Silvano Cerza <3314350+silvanocerza@users.noreply.github.com>

People might get the impression that, since the documentation is in the Arduino CLI repo, it only applies to Arduino CLI.
However, since Arduino CLI is used in some form in most of Arduino's development tools, much of the information is
universal.

* Added documentation for pluggable monitor

* Apply suggestions from code review
Co-authored-by: per1234 <accounts@perglass.com>

* Add pluggable monitor spec in nav bar; fixed link in source code comments

* fix i18n and lint warnings
Co-authored-by: per1234 <accounts@perglass.com>

* Added silent mode for monitor

* Added --config flag to monitor command

* fix i18n

* Applied review suggestions

* rename --silent to --quiet
* removed useless 'settings' variable
* translation string for "Monitor port settings" in CLI mode

* Implementation of Monitor business logic

* Implementation of 'monitor' command of the CLI

* fix i18n

* Update commands/monitor/monitor.go
Co-authored-by: Silvano Cerza <3314350+silvanocerza@users.noreply.github.com>
Co-authored-by: Silvano Cerza <3314350+silvanocerza@users.noreply.github.com>

* Resolve monitors from platform.txt

* Implementation of monitor --describe command

* fix i18n

* Added new Monitor command (will replace current Monitor service)

* Added new EnumerateMonitorPortParameters gRPC call

* Force compile error on gRPC deamon when there are unimplemented methods

* Updated deamon implementation stub

* fix i18n

* Added bundled instance of serial-monitor

* Download serial-monitor together with other bundle tools

* fix i18n

* Fixed race condition in pluggable monitor

Many methods had the stateLock held for the entire scope of the function
call but the 'port_closed' message can be received at any moment,
asyncronously, and it requires a stateLock as well. In this case the
worst case is that the decode loop is blocked for 10 seconds until the
timeout occurs, but this is not ideal.

This bug has been fixed by removing the state, since it's not really
useful.

* Improved message logging in pluggable monitor

* Refactored message processing in pluggable monitor

* Fix i18n

* fixed lint suggestion

* fix from code review

* Addde QUIT command in monitor-client

* Use rpc.Port in pluggable monitor Open method

* Slightly improved monitor client error messages

* Fixed resource leaking in PluggableMonitor client

* fixed i18n

* Fixed test... ooops

A bug introduced in the 3.9.7 release of Python causes a spurious failure of the
`test\test_lib.py::test_install_git_invalid_library` integration test:
https://bugs.python.org/issue45121

As a workaround, the last working version of Python must be used: 3.9.6. In order to ensure this is done when running the
integration tests locally, this version is specified in the Poetry configuration. Even though only the integration tests
require this version limitation, the Poetry configuration change affects all processes that use Poetry. Since only the
integration test workflow was adjusted accordingly, the other workflows using Poetry continued to explicitely install
a version of Python that did not fulfill the version constraints specified in the Poetry configuration. It seems it was
possible for Poetry to find a compatible version on the runner:

> The currently activated Python version 3.9.7 is not supported by the project (>=3.8, <3.9.7).
> Trying to find and use a compatible version.
> Using python3.8 (3.8.10)

but this additional output caused a failure of the "Deploy Website" workflow due to expecting only valid JSON as the
output from the siteversion.py script:

```
Error: The template is not valid. Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: T. Path '', line 0, position 0.
```

Even though the other workflows were able to continue to work with the discovered Python 3.8.10, it seems safest avoid
reliance on whatever Python the runner happens to have installed and instead explicitly install the Python version we
want to be used. So the full pin of Python is done in all workflows that use Poetry.

Since it is convenient to get automatic updates for Python patch releases, this full pin should be reverted back to the
"3.9" minor version pin once a new version of Python is released with the bug fixed and added to versions available for
installation via the `actions/setup-python` GitHub Actions action.

On every push that changes relevant files, and periodically, configure the repository's issue and pull request labels
according to the universal, shared, and local label configuration files.

[skip changelog] Add partition load query before fetching metrics and schedule extraction 3 times a day (#1471)

* Fix library verification when installing from git repo or zip file

* Enhance code comments and unit tests
Co-authored-by: per1234 <accounts@perglass.com>
Co-authored-by: per1234 <accounts@perglass.com>

* Fixed leaking pipes in Discovery command creation

Moved the process creation at the very last moment, since StdInPipe and
StdOutPipe methods actually create an OS pipe even if the process is not
started later.

* When a discovery is quitted ensure that the process gets Wait-ed

Otherwise, the resources allocated by the process will be leaked.
(pipes, zombie process, etc.)

* fix i18n

TrimRight greedily removes as any matching characters from the cutset as possible which can inadvertently remove characters from the library name.

This PR will replace the download data query for gather CLI downloads data

PLEASE NOTE: I'll proceed also to replace the `AWS_ATHENA_SOURCE_TABLE`  secret with a new table name

Arduino library authors may chose from multiple structures, each of which have different implications for the compilation
of the library source files. The specification explains this in a somewhat simplistic manner as "1.5 format" and
"1.0 format". That is sufficient for most, but does not provide a complete picture. Feedback indicated that more advanced
users were left wanting complete documentation, which is provided here.

The subject is not well suited for description via prose, so a chart and table are employed instead.

The chart is defined in the DOT graph description language.