Version 4 - switch dev over (POM removal remains)

[planetf1]

Following release 3.15 we will move over to development of Egeria version 4.
This will require a change to use Java 17 & build off gradle

This issue will track the immediate changes required.
The starting point will be a post-release 3.15 update to 3.16 SNAPSHOT

• Get agreement on dev community call that this work can now begin
• Mailing list, slack, github discussions announce of start of work & need to use java 17/gradle
• Update egeria-release-4.0pre from main via rebase (check clean)
• Merge in changes from egeria-release-4.0pre back to main
• Disable v4 github actions on egeria-release-4.0pre
• Update version in main from 3.16-SNAPSHOT to 4.0-SNAPSHOT
• Mailing list, slack, github discussions announce of need to use java 17/gradle
• Test cts
• Test notebooks
• Ensure docs updated
• Remove maven pom files
• Check other scans - codeql, dependencies etc

Additional work will then be required in other repositories to bring them up to the current levels ie connectors that pull in base egeria libraries.

[planetf1]

We are starting this switch on MONDAY 6 Feb 2023
Maven POMS will not be delete for the first stage

[planetf1]

v4 changes merged.

One issue noticed on build

> Task :open-metadata-test:open-metadata-fvt:view-services-fvt:glossary-author-fvt:publishMavenmodulePublicationToMavenLocal
Multiple publications with coordinates 'org.odpi.egeria:glossary-author-fvt:4.0-SNAPSHOT' are published to repository 'mavenLocal'. The publications 'mavenmodule' in project ':open-metadata-test:open-metadata-fvt:access-services-fvt:glossary-author-fvt' and 'mavenmodule' in project ':open-metadata-test:open-metadata-fvt:view-services-fvt:glossary-author-fvt' will overwrite each other!

[planetf1]

This was caused by incomplete moving of the glossary-author-fvt from access-services to view-services - there was a old reference in settings.gradle.

[planetf1]

Another issue noted.

The build is set to

• read/write to cache for builds on main
• read only from cache for PR builds

If a PR is submitted which can be satisfied purely from cache, then when the codeQL workflow attempts to run,
it finds no code to use...

The fixes are to do one of:

• Not use codeQL
• make codeQL non-mandatory (ie it's not checked for allowing PR to be merged)
• Add ability for user to ignore codeQL failure
• selectively use codeQL action based on what files change (very hard to specify)
• Disable caching for codeQL build (increases build time)

[planetf1]

See #689 for docs updates

[planetf1]

complete