X509 certificate provision

[AndriiLandiak]

Pull Request description

Related issues: #6735, #7668

UI changes:
Device profile entity -> Device provisioning -> component DeviceProfileProvisionConfigurationComponent -> added form controls for provision strategy "X509 Certificates Chain".

Screenshots:

General checklist

• You have reviewed the guidelines document.
• PR name contains fix version. For example, "[3.3.4] Hotfix of some UI component" or "[3.4] New Super Feature".
• The milestone is specified and corresponds to fix version.
• Description references specific issue.
• Description contains human-readable scope of changes.
• Description contains brief notes about what needs to be added to the documentation.
• No merge conflicts, commented blocks of code, code formatting issues.
• Changes are backward compatible or upgrade script is provided.
• Similar PR is opened for PE version to simplify merge. Required for internal contributors only.

Back-End feature checklist

• Added corresponding unit and/or integration test(s). Provide written explanation in the PR description if you have failed to add tests.
• If new dependency was added: the dependency tree is checked for conflicts.
• If new service was added: the service is marked with corresponding @TbCoreComponent, @TbRuleEngineComponent, @TbTransportComponent, etc.
• If new REST API was added: the RestClient.java was updated, issue for Python REST client is created.

Front-End feature checklist

• Screenshots with affected component(s) are added. The best option is to provide 2 screens: before and after changes;
• If you change the widget or other API, ensure it is backward-compatible or upgrade script is present.
• Ensure new API is documented here

[volodymyr-babak]

Why do you prefer to ignore this exception?
I believe in real case production that includes a lot of potential points of failure, it's important quickly understand where is the root cause of the problem and warn message in the core engine that certificate cannot be parsed or common name cannot be obtain could help on this.

[AndriiLandiak]

I realize that it's not obvious, but this error occurs if we cannot read and create an X509 object from a certain String representation (I mean readCertFIle in such case from chain.get(0)), so I am not sure it's the right warning message. But I'll provide an additional warning in the method parseCommonName if we cannot do it.

[imbeacon]

Could we just add a field to ProvisionDeviceCredentialsMsg?

[AndriiLandiak]

I don't think so. This is not a classic provision strategy, in most cases, it will work as before - connect to devices, so I believe that sending CredentialsDataProto with empty fields to connect is a bad approach.